LINE Developer Meetup #8 in Kyoto に行ってきた話しLINE Developer Meetup #8 in Kyoto に行ってきた話し

<< | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク >>

最近 不勉強であまり勉強会とか技術イベントに参加できてなかったのだけど、@rim2r に面白そうなイベントがある!っと誘いをうけて楽しそうなので参加してきました。

images.jpg

LINE Developer Meetup #8 in Kyoto - connpass

仕事で触ってる範囲はフルスタックな感じなんだけど、規模がとても小さいので自分みたいなのが行っていいのかなーっと思ってたけど、興味深い話しばっかりで凄く面白かったので行って良かった。

 

会場は京都駅から南に下った所の京都テルサの会議室。

テルサはスポーツ施設しか利用した事がなかったので、ちょっと新鮮な感覚だった


こっからは会場で取っていたメモベースにまとめたもの。

すぐ纏めないとすぐ忘れるのでとりあえず書いとかないと。

起きたら読み直して変な所はなおします...Zzz...

 

あと今回はノート持ってくの諦めて、z ultra と BTキーボードでメモ取ってみた。

 

WKWebViewはデキる子か @tarunon

LINE のインターン生で未踏プログラマーな @tarunon さんによる、iOS8 で追加された WKWebView は従来の UIWebView と比べてどうなのか...というお話。

 127.jpg

といった感じで、最初はまず UIWebView でサードパーティーブラウザを実装するのがどれくらい大変なのか...というお話から。

WEBビューをアプリに組込むって時に使われるコンポーネントとしては最低限の機能は持ってるんだろうけど、ブラウザを実装するにはあまりにも機能が足りない...

 

そこで3つの拡張手法でブラウザの必要な機能を実装していく。

「JS による拡張」「ネットワークによる拡張(NSURLProtocolによる)」「プライベート API (!)で頑張る」

特に NSURLProtocol でコンポーネント側でサポートされているスキームのリクエストまでフックして色々弄れるって話しは面白かった。

(しかしこれを時前でやるのはキツいな...

この辺一通り、どーいった機能が足りなくてどう制限を回避していくのか、というのが各機能の表で見やすく整理されて解説されていて面白かった。

 

んで、WKWebView はデキる子か?という話しで、上記の UIWebView がサポートしていなかった機能の大半をサポートしている!

素晴しい!

でも NSURLProtocol が上手く動かないので使えない!残念!

WKWebView のが便利なシーンはかなりあるけど、サードパーティブラウザを開発するには適材適所で今後も UIWebView と付き合っていきましょう...というちょっと寂しい感じの締めだった。

 

質問し損ねたけど、「NSURLProtocol が上手く動かない」部分がブロックされた機能なのではなく不具合であるなら将来的には WKWebView に移行してく事もありうるのかな。

「この先」の話しもちょっと聞きたかった。

 

 

LINEバックエンドとマイクロサービスアーキテクチャ @小野さん

最初は LINE の運用規模のおさらい。

ググれば出てきそうな情報ではあったのでメモってないけど、ユーザーは日本に偏ってるのかと思えば案外台湾やタイが多い。

popもかなり世界中に散ってて、サポセンの拠点も今では世界4箇所に。

 

・マイクロサービスアーキテクチャ

サービスを広げると、システムはどんどん巨大化していく。

低コスト・スピード重視で開発を続けていくと、いずれ巨大なモノリスが出来あがる。

結果コストは増大し、スピード感が落ちる。

全てを把握しないと何もできなくなり、新しい事に挑戦できないエンジニアのモチベーションは低下していき山手線を彷徨う。

 

・LINE は?

複数の独立したコードベースでチーム単位に動ける。

→コミュニケーションコストが低い。 新しい技術もサービス単位でガンガンいれれる。

→もちろんチームによって差があり、コアな所はとてもコンサバ。

データ管理なんかもチーム毎に違う手法をとるので、採用DBもバラバラだったり。

(HBase,Redis,MySQL,MongoDB,InfluxDB...

→ビルド、デプロイ、モニタリング、ログ収集なんかの基盤部分は専門のチームがやっている。

 

・API

サービスごとに API セットができる。

→インターナルな API で json on http とか必要なのだろうか?

自由度が高すぎるとサービス毎にスタイルがバラバラになる。

それを統一する為にはドキュメント等で縛らねばならないし、それすら従わなかったりする。

 

その為採用したのが serialization/RPC フレームワーク 『Apache Thrift』

まず、Thrift IDL で定義ファイルを書いて、各言語ごとに必要なコードをそこからジェネレートする為、API の定義ファイルがドキュメント代わりになる。

→ WIKI を管理する必要がなく、また多国籍なエンジニアが開発に参加し多言語化している環境でも翻訳を意識する必要がない。

line ではこの定義ファイルを git で管理し、API の更新時はブランチを切って更新していき、利用するサービス側はそれを見て実装を進める。

主要の言語はサポートされている為、開発言語から違うチーム間でもやりとりが可能でプラガブル。

 

何より話し聞いててでかいなと思ったのがエラーハンドリング。

json だと手法が固まってない所為で割りと適当にバラつきがちなエラーハンドリングだけど、Thrift だと各言語に最適な形でエラーハンドリングができ、例外が扱える言語ならちゃんと適切な例外が飛んでくる。

便利!

 

・マイクロサービスのトレーサビリティ

複数のシンプルなサービスをいくつも介してサービスを提供している。

マイクロサービスのいい所は、サービス単体の完成度をあげていけば 全体で何が起きているか把握しなくてもいい所だ。

 

ほんとうに把握しなくても大丈夫なのか?

実際に何が起きているのか。

(この時のぐちゃぐちゃした感じの図が大変わかりやすかったw

クライアントまで到達する間に複数のサービスをいったりきたりしている。

結果、「何か」が起きた時に原因を究明したくても、どこのサービスが原因なのかが分からないし、それを調査する責任者が誰なのかすら分からない。

詳細を把握しなくてもいいのはいいが、パフォーマンスのボトルネックが可視化できない。

 

そこで登場するのが Google の論文を元に Twitter が作った『Zipkin

単体サービスでボトルネックになっているものを Firebug で探すように、結合されたサービスの中からボトルネックになっている部分をタイムライン形式で表示して可視化できる。

また非同期的なものを可視化できる。

(実際にキューを積んで処理してる図がわかりやすかった。

 

どのように動くのか?

サービス間のやりとりをスパンとして木構造で集約していく。

実際にはクライアントと各サービスのリクエスト・レスポンスのタイミングでロギングしていく。

またデバッガーにブレークポイントを仕込むように、コード上の任意のタイミングでのロギングも可能な為、サービス内の処理も切り分けて視覚化できる。

 

構成としてはサービスからScribeでログを受け取るコレクタ、コレクタが受け取ったデータを溜めるストレージ、ストレージから検索機能を提供するクエリサーバー、そしてそれらの集計した結果を表示するWEB UI で構成される。

ストレージは Twitter が最近まで使っていた Cassandra が一番テストされていて熟れているが、運用実績を考慮して HBase に。

また各サービスに zipkin-collector とのやりとりを実装してもらうのはコストが高い為、サービス間で Thrift によるリクエストを受けたタイミングでフィルタに通す形でログに保存するデータを収集して Scribe プラグインをいれた fluentd 経由でログを送信している。

 

今後は収集したログをよりインテリジェントに分析できるように、またトレーシングの導入コストをより軽減させるライブラリをつくって可能であれば公開したい とのこと。

 

 

というような事をまとめがてら、記憶の不確かな部分を調べる為に検索していたら、本家の記事があったので、こちらを読みましょう。

LINEのマイクロサービス環境における分散トレーシング « LINE Engineers' Blog

図もあって大変わかりやすい。

 

 

懇親会と二次会

現在のエンジニアさんの分布だとか福岡の新オフィスの話しとか、福岡のサポセンの話しとか、他言語化初期のサポセンの苦労話しとか、社内言語の話しとか、なぜ京都開催になったのかとか色々とお話が聞けた。

なんでテルサになったの?というか「なんではてなじゃないの?」みたいな会話が面白かった。

 

あとは大手サービスの裏側を支えるエンジニアみたいな話題で某大手動画配信サイトの話しなど聞けたのが楽しかった。

勉強会で色んなエンジニアが集まれば色んな繋がりがあるもんだなぁ。

最後まで居たら終電逃して途中駅から歩く感じにはなったけど、ほんとに面白い話題しかない みたいな感じで過せたので とても楽しかったしモチベーション上がる感じでした。

次回もし関西(大阪でも)開催されたら参加したいな。

はてなオフィスだといいなー。

 

宣伝

それはそれとして、明日(というか今日10/18)の夜22時からプログラマーズナイトというイベントがあります。

プログラマーズナイト第5夜 - connpass

プログラマーやらエンジニアが集まって、素敵な音楽が流れる中お酒を呑みながらあーだこーだ話したり、しゃべりたい事をLTしたりするイベントです。

LT する人も現地でまだまだ募集してるし、「こんなサービスつくったぜ」みたいな宣伝がてら技術解説するLTとかでも歓迎...のはず。

夜22時から朝4時までのオールナイトイベントなので、近くで飲んでで帰りそびれた人なんかも ふらっと立ち寄ると楽しいかもしれません。

 

まぁなんか聞かせたい人も聞きたい人も、だらだらだべって酒のみたい人も是非。

トラックバック(0)

トラックバックURL: http://exe.tyo.ro/mt/mt-tb.cgi/1955

コメントする

2014年11月

            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            

月別 アーカイブ

2014年
2013年
2012年
2011年
2010年
2009年
2008年
2007年