レポート

SPECIAL REPORT「LINE DEVELOPER DAY_2015 Tokyo」

この記事を読むのに必要な時間:およそ 4 分

午後のセッションをミニレポート

ランチサービスが提供されたお昼の休憩を挟み,午後はホールA,Bの2つの会場で15のセッションが行われました。そして最後はホールAで,全登壇者の参加による座談会も開催されました。ここでは,午後のセッションからいくつかピックアップしてご紹介します。

LINEの膨大なデータを扱うストレージシステム

中村俊介氏によるセッション「HBaseとRedisを使った100億超/日のメッセージを処理するLINEのストレージ」では,LINEのストレージシステムについて解説されました。そこに求められるのは低遅延とゼロダウンタイムです。さまざまなOSSを試した結果,現在では高速で多様なデータに対応する「Redis」と,高速性とスケーラビリティの高い「HBase」の組み合わせを使用していると言います。LINEのデータは,メッセージなどが100TB以上,ユーザのソーシャルグラフが10TB以上,統計データは10PBの容量を扱っており,これらをRedis,HBase,そしてHDFSで運用しています。

また可用性においてはRedisをチューンアップし,ノード障害と遅いレスポンスのすばやい検知,I/Oのオーバーヘッドの削減などを行い,現在Redisのクラスタは,30のクラスタ,4,775のシャード,48TBのメモリを使用していると言います。一方,HBaseではタイムアウト関連のチューニングや,クラスタの冗長化などを行っています。HBaseのクラスタは,15のクラスタ,1,300のFusion-io ioDriveおよびHDDノード,1PBを使用しています。また,運用においての改善についても詳しく説明しました。

中村氏は今後の課題として,古いバージョンのアップデートをはじめ,複数のデータセンターの利用,Opsツールの向上,OSSコントリビューションを挙げました。

スマートデバイス向け開発最新動向

「LINEのiOS対応,新しい技術チャレンジ」と題されたセッションでは,LINEにおけるiOS向け開発の最新動向について紹介されました。

最初に登場したのは,Christopher Rogers氏。同氏は,イベントの数日前に発売されたばかりのApple Watch向けLINEアプリの開発について,現段階での問題点と解決方法について触れました。

Rogers氏はこれまでの開発経験をもとに,現段階でApple Watch向けアプリを開発する際には,⁠通知Actionの追加は慎重に行う」⁠よく使う画像はApple Watchにコピーしておく」⁠openParentApplicationとapp groupはほどよく使う」といったことに注意するとよいとして,発表をまとめました。

次に登場したのは,石川洋資氏。⁠Swiftによる開発チームの変化」と題し,LINEおよびFamily Appsの開発における問題点とその解決策としてのSwift採用について説明されました。

Swiftを採用したことにより,⁠開発の分担やデバッグがしやすくなる」⁠コードレビューが簡単になる」⁠安全なコードが書かれやすくなる」といったように,チーム開発で問題になり得る点をカバーできるようになったと言います。一方で,Swiftの場合,⁠ほかの言語に比べて)設計の良し悪しがインタフェースに出やすいことを注意点として挙げました。LINEではこの点の品質を高めることを意識しながら,今後もiOS向けアプリの開発環境としてSwiftの導入を進めていくそうです。

役立つデータ分析プラットフォーム構築を目指して

橋本泰一氏による「ビッグデータを活用するための分析プラットフォーム」では,LINEにおけるデータ分析について,分析プラットフォーム構築のポイントとそのグローバル化で見えてきた課題が紹介されました。

橋本氏はまず,データ分析は「データの集約」⁠サービス状況の報告」⁠サービスの問題点や改善点の分析」という3つのフェーズに分かれると述べ,データの集約においてはリーズナブルに大量のデータを保持することが,状況の報告においては柔軟なデータの設計とわかりやすい可視化が,問題点や改善点の分析においては簡便で高速なデータの抽出がポイントであると述べました。そして,各フェーズで使っている技術を紹介したのち,こうした技術選定の際に重要視していることとして「API連携がしやすいこと」⁠なるべくOSSを使うこと」⁠コストに見合わないユーザトラッキングをしないこと」⁠認証をしっかり行うこと」といった点を挙げました。

最後に橋本氏は,グローバル化に際して分析すべきKPIが増加しており,すべてを人の目で確認するには負荷が高過ぎるという課題を挙げ,KPIの特徴的な変化のみを伝えるしくみを開発中であるとして発表を締めくくりました。

LINE Creators Marketのシステムと国際化

松野徳大氏写真3によるセッション「Webサービスの国際化にあたりLINE Creators Market開発がどのように行われたか」では,LINEが爆発的に普及する一因となったスタンプを誰でも作成して販売できる「LINE Creators Market」の開発およびグローバル対応について紹介しました。同サービスのポイントは,⁠誰でも参加可能」⁠売上の50%をクリエイターへ」⁠世界中に販売可能」の3点です。サービス開始後6ヵ月で,登録クリエイター数は27万人,登録されたスタンプは9万セット以上に伸びています。また,上位10位の平均販売額は3,680万円,販売1万円以上のスタンプは全体の40.8%を占めています。販売総額は35億9千万円に上っています。

写真3 LINE Creators Marketの国際化について語る松野徳大氏

写真3 LINE Creators Marketの国際化について語る松野徳大氏

技術的な面では,主要機能として大きく「ステッカーのアップロード/管理」⁠画像処理」⁠承認機能」⁠統計情報の表示」⁠送金」の5つに分けられます。全体のアーキテクチャとしてはマイクロサービスとして設計されており,Perlで書いていると言います。国際化への対応では,送金が国内では銀行でしたが,国外ではPayPalを利用すること,統計情報をCSVでrsyncdに渡して集計プログラムを介してMySQLに送ることなどが挙げられます。このほか,翻訳の社内実施や,アジャイルな開発であること,スケール前提で開発すること,監視が重要であることなどが説明されました。

新たな「LINEメッセージングパイプライン」

小野侑一氏による「Akka ActorとAMQPで作るLINEメッセージングパイプライン」というセッションでは,LINEメッセージングパイプラインをリプレースした内容について紹介しました。パイプラインとは,ユーザのデバイスと外部システム間でやりとりされる受信キュー,送信キューのしくみです。メッセージングでは,送信した順序で受信側に到達しなければならないという基本要件があります。Producer/Workerパターンでは処理順序が保証されないため,挿入順に処理される1Q1Cを採用したと言います。しかし1Q1Cには,コンシューマーのフェイルオーバーをどう実現するか,1キューに対して正確に1コンシューマーを割り当てる方法といった問題もありました。

そこで,AMQP ACKを活用した1Q1Cのフェイルオーバーを採用した結果,AMQP(RabbitMQ)のみでフェイルオーバーが可能になり,キューとコンシューマーのペアリングが容易になり,スケールアウトも解決するなど,可用性,スケーラビリティともに有効だったと言います。さらに,ScalaおよびJava向けの並行プログラミングライブラリ「Akka Actor」を組み合わせました。Akka Actorは,Receive Functionの切り替えを可能にし,内部ステートを引き継ぎつつ状況に応じて動作を定義できる,複雑なメッセージフローの制御に有利といった特徴があります。非同期パイプラインを実装することで,スループットを落とすことなく,複雑な要件を同時にクリアできたといいます。

「座談会」では,講演者が会場の質問に回答

本イベントでは,カンファレンス公式のLINEアカウントを作成し,参加者から質問を募っていました。最後のセッションでは「座談会」として,セッションの講演者12名が参加して,このアカウントに寄せられた質問に答えました写真4⁠。モデレーターは田中洋一郎氏が担当しています。採用された質問は,登壇者に合わせて12個。⁠マイクロサービスではサービス間の通信が増えませんか?」⁠iOSのバージョンによる互換性の問題で困ったことはありませんか?」など開発者らしい質問が出ました。

写真4 座談会では講演者が勢ぞろいして質問に答えた

写真4 座談会では講演者が勢ぞろいして質問に答えた

さらに「Swiftの体得はどのようにしましたか?」⁠これから崩壊しそうなところはありますか?」といった突っ込んだ質問や,⁠MySQLかRedis+HBaseかの選択をする基準の分岐点は?」のような具体的な質問もあり,登壇者が詳しくわかりやすく回答する姿が印象的でした。