ニュース
LINEが開発体制、グローバル対応の秘策、サービス基盤の変遷を解説
エンジニア向け大規模講演イベント「LINE DEVELOPER DAY_2015 TOKYO」
（2015/4/28 16:56）
LINEは、エンジニアを対象とした大規模な講演イベント「LINE DEVELOPER DAY_2015 TOKYO」を都内で開催した。東京・渋谷のヒカリエホールで開催され、午前中には基調講演の枠として4名が登壇、「LINE」がこれまでに築き上げてきた開発体制やグローバル対応での施策、サービス提供当初から変遷してきたシステムの中身などが、それぞれの担当分野で解説された。
これらはいずれもLINEの思想や意気込みを反映した“概要”で、「LINE」の開発・運営にまつわる技術的・専門的な解説は午後のセッションで用意された。
CEO出澤氏、「世界戦のチケットを手に入れた。これからが本番」
イベントの冒頭に登壇したのは、LINE 代表取締役社長 CEOの出澤剛氏。出澤氏は、「LINE」はユーザー数が急激に拡大したサービスとし、グローバル展開やプラットフォームの多様性という意味では「立ち向かってきた」と、挑戦の連続だった様子を振り返り、「挑戦の軌跡、目指している世界を感じてもらえれば」とイベントに集まったエンジニアに語りかけた。
「LINE」は、2014年12月時点で、グローバル全体の月間アクティブユーザー数は1億8100万人。1日あたり170億回のメッセージの送受信が行われている。日本のユーザー数は5800万人で、ユーザー数は1000万人を超える国・地域は13カ所。日本と台湾、タイではトップシェアを獲得しているという。「SNSなどでトップシェアは重要で、2番手、3番手は過疎化していく」とトップになることの重要性を語り、「我々の非常に大きなテーマがローカライズ。徹底的に、多面的にローカライズしている」と、海外市場への対応も重視している様子を語った。
出澤氏からは、ここ4カ月以内にリリースされたという「LINE Maps for Indoor」や「LINEバイト」といった、メッセージングだけでなはない、プラットフォームとして「ライフ系」（出澤氏）の取り組みが、もうひとつの大きな軸になるとし、「グローバルとライフ（系プラットフォーム）、これから2つの軸で成長していく」と「LINE」が目指す大きな方向性を示した。
「世の中的には成功したと言われるが、これから本当の本番が始まる。世界では、もっと強いビッグプレイヤーが占めている。非常に大変な山を登っていくことになる。スマートフォンの大変革期に“世界戦のチケット”を手に入れたのは幸運なことだ。そうした中で誇りに思っているのはエンジニアたちだ」と、出澤氏は集まったエンジニアに意気込みを語った。
信頼と尊重で「優秀なエンジニアをサポートするだけ」
出澤氏に続いて登壇したのは、LINE 上級執行役員CTOの朴イビン氏。朴氏はグローバルにまたがって開発されるLINEの“開発カルチャー”が解説された。
朴氏が示した概要はシンプルで、「優秀なエンジニアをサポートするだけ」というもの。同社で「Autonomous Teams」（主体的なチーム）と呼ぶ体制は、サービス単位でエンジニアを抜擢してチームを組み、チームに裁量を与え、最後まで担当者が開発するというもの。サービス内容に応じた最適な人材で構成されるほか、コードベースでやりとりし、エンジニアの“意思”を可視化するというコラボレーションツールにより、同時に会議が難しい、世界中の拠点に散らばる開発者と共同開発が可能になっている。
同社ではまた、「Cold-Case」として、過去に何らかの理由で頓挫し凍結されてしまったプロジェクトに対し、ほかのエンジニアが解決に挑んでプロジェクトの再起を図る取り組みが紹介された。これらでは、参加したエンジニアは自分の領域が広がるといったメリットもあるという。
朴氏は、こうした開発体制や開発サイクルを支える思想が「信頼と尊重」とする。「（信頼と尊重が実現されていれば）開発コストを削減されても、信じるようになる。仕事は最後まで自分でやることで、プロジェクトの成功率は高くなる。コードレビュー（ソースコードの査読）も、参加者は同じ責任者としてフィードバックすることが大事。相手を尊重する意識の上で行われるとき、成熟したコードレビューが可能になる。ポジティブなプレッシャーが起こり、それが自然な環境になる。プロジェクトに参加しなかった上司からの評価は意味がない。同僚の評価が重要で、上司はそれをまとめる役。我々は、優秀なエンジニアをサポートするだけ」と、現場のエンジニアの環境構築や、ポジティブなサイクルの醸成に努めている様子が語られた。
「世界のエンジニア達が、グルーバルプレイヤーを目指している。しかし、日本のほとんどのエンジニアはシリコンバレーを目指している。グローバルプレイヤーとして活躍しているLINEのように、日本から出発したグローバルサービスを、ともに、もっと作っていきたい。アジアがリードするグローバル化、ということが可能だと信じている」と、朴氏は最後に、アジア発のグローバル化への参画を訴えた。
海外の地下鉄、エレベーター――現地で対処する「LINE遠征隊」
3番目に登壇したLINE 上級執行役員 サービス開発担当の池邉智洋氏からは、サービスを提供している各国に飛び、現地でサービス環境の調査や調整を行う「LINE遠征隊」と呼ぶ取り組みが紹介された。
「LINE遠征隊」（通称）は2～6名のエンジニアで構成され、平均して4日程の滞在期間中、SIMカードを購入するなど現地のユーザーと同じような通信環境でサービスを利用し、事前に判明している問題の原因を調査したり、非常に多いという、現地で判明する新たな問題を解決したりする部隊となっている。滞在中はレストランや地下鉄、ホテルのエレベーターなど、詳細に調査され、場合によっては現地の通信キャリアと連携しながら、繋がりにくい、遅延がおこる、といった問題に対処していく。最近では、航空機の中で提供されるWi-Fiでも調査や調整を行ったという。
また、例えばパキスタンからの無料通話の宛先は、パキスタン国内ではなくサウジアラビアにかけるユーザーの割合が最も多いというデータも示し、ひとつの国の問題に対処するだけでは、品質の改善が体感できない場合もあるとした。
「LINE」が比較的早期に普及した外国として挙げられるのがスペインだが、サービス開始してまもなく、スペインからは突出して、電池がはやく減るというクレームが多かったという。原因は、当時市場で流行りのAndroid端末のバッテリー容量が少なかったことや、地下鉄で非常に電波が途切れやすかったことなどが、電池消費を加速させていた原因ではないかとし、「LINE遠征隊」の調査で判明して対処を行ったという。
「日本で考えていても気づけない。みんなが持っている端末を見たり、使ってみたりして気づく。スペインは遠征隊の活動があって対処できた。英語も通じない国もあって大変なことも多いが、グルーバルに提供するというのは、日本でひとつのものを提供すればいいということではない。各国に赴いていくのが重要。システムのログで送信失敗などのエラーが把握できるようになっており、日々品質を改善しているが、人間が感じる、エモーショナルなものと、両方が必要」と池邉氏は語り、グローバルサービスの提供にあたって、現地で体験することの重要さを語った。
急速な普及に対処したアーキテクチャの変遷
午前中で最後となる4番目には、LINE 開発1センター LINE開発1室 所属のTom.T氏が登壇、LINEのプラットフォームを支えるアーキテクチャとその変遷、組織といった、技術的な分野が紹介された。
Tom.T氏が示したのは、「LINEメッセージング基盤の進化」「LINE流マイクロサービス」の2つのテーマ。マイクロサービスは業界で流行している考え方だが、この言葉や考え方が一般化する前から同じ内容で取り組んでいたという。
「LINEメッセージング基盤の進化」は、2カ月で開発しリリースしたという、2011年6月のサービス開始当初から、現在の巨大な処理を行えるプラットフォームになるまでの苦労の歴史ともいえる内容。
最初期のアーキテクチャはシンプルで一般的な構成で、Pollingを使ったメッセージングの送受信に、Push通知を挟み込んだよりリアルタイムに近い送受信の仕組みを加えるものの、外部に依存するPush通知は遅延などをコントロールできず、またPollingに依存することで「モバイルアプリとしては致命的に電池を食っていた」（Tom.T氏）という。
リリースから2～3カ月後には、Long Pollingを実装、クライアントとサーバーの中間にゲートウェイを設置することでPush通知に代わる環境を構築した。ApacheのリバースプロキシをNginxと拡張モジュールに置き換えたもので、この構成は現在までの基本になるアーキテクチャになっているという。
その後、ユーザー数が1000万人を超えるようになると、別の理由として、「Segmentation Fault」（セグフォ）地獄に陥るようになる。これは、Nginxと拡張モジュールの実装に起因したもので、同期処理を「ちゃんとやって」安定化させることができたものの、「メッセージングのコアで、不安定さを抱えている。シンプルに、安全にできる方法はないのかと考えるきっかけになった」（Tom.T氏）。
Nginxと拡張モジュールに限界を感じたという同氏は、「ErlangでNginxを置き換えた。シンプルに書き出せるのが我々に合う感じだった。分散処理や、抽象度の高いコード、無停止デプロイができるのもメリット。通信会社で発明された言語だが、メッセージングにもマッチした」と経緯を振り返り、Erlangを導入したゲートウェイ部分を「LEGY」（レギー、LINE Event Delivery Gateway）と命名した。
2012年7月ごろには、クライアントとサーバーとのコネクション数が多すぎるという問題も顕在化。通信キャリアと連携して対処する一方で、「プロトコルレベルで改善した例」として、HTTP（S）に代わってSPDY（スピーディ）に切り替えたという取り組みを紹介した。当時SPDYはGoogleが開発し、ドラフトの段階だったというが、「直面していた問題を解決するもので、迷うことなく、クライアントとLEGYに実装した」という。結果的に、世間ではSPDYがHTTP/2の元になった。同社ではSPDYの導入により、コネクションの多層化などの効果で、トータルコネクション数は半分から1/3にできたとした。
海外でのサービスの普及が本格化すると、日本のサーバーから遠いという物理的な課題から、遅延といった問題も浮かび上がる。同社は「Global POP（Point of Peer）」と呼ぶデータセンターを世界中に配置。フロントエンドにあたるLEGYを設置した上で、LEGYからサーバーまでは専用線とすることで、改善を図った。通信速度が遅い地域では、LEGYから、送信完了前に送信完了のイベントをクライアントに返す（最終的にエラーがあった場合は再送が指示される）といった、主にユーザー体験を改善する仕組みも取り入れられている。
各サービスが個別に開発されAPIで繋がる「LINE流マイクロサービス」
「当時はその言葉はなかった」というが、新しいサービスや機能、品質、そしてスピードが求められる業界で、同社が採用したのがマイクロサービスの原型になる考え方。個々の機能をサービスとして開発し、APIとジョブキューでつなぐというもので、メッセージングサービスの核になる「Talk-server」が中心にあり、ほかの機能はすべてAPIでつながっている様子が示された。各サービスは開発言語もバラバラで、独立して開発されているという。「全体としてはシンプルで、効率よく開発できる」とメリットを語る。
しかし、マイクロサービスのように「分けられないとろもある」という。これは朴氏の解説でも触れられた組織・チームの形態で、チームに対して独立した裁量を与え、「海外の開発拠点や会社をまたいで、作るべきものに、必要な人を選抜して作る」とした。
このほか、プロトコル管理として、インターフェイス定義言語（IDL）でまず定義し、テキストベースで、GitHub上でディスカッションを行い、「このAPIはイケてないといった、こういうところから、しっかりとレビューするのが重要になる」と解説する。
同氏からは、今後の課題についても少しだけ触れられた。まずはマルチデータセンター化で、Global POPとしてLEGYを設置しているフロントエンドサーバーを、ちゃんとしたサーバーに置き換える点だという。「欧州のデータセンターは目下取り組んでいるところ」とした。
「“マイクロサービス”と格好をつけているが、問題点もある。Talk-serverは実は巨大になっており、今後は分割していかないといけない。また、あるサービスが落ちたときに全体がどうなるか、管理ができていない。これからきちんと整備していかないといけない」とし、マイクロサービスについても継続的に改善していく方針を示している。
