LINEのトップエンジニアが語るiOS／Androidアプリ、サーバー、Webフロントエンド開発の裏舞台：LINE Developer Conferenceまとめリポート（後編）（1/2 ページ）

「LINE Developer Conference」の締めくくりのイベントとして開催された公開座談会「Fire Side Chat」では、LINE社内で中心的な役割を担うトップエンジニアが一堂に会し、苦労話や失敗談などLINE開発の裏舞台を披露した。

» 2014年05月07日 18時00分公開

[益田昇，＠IT]

　LINEは4月15日と17日の両日、世界初となる「LINE Developer Conference」を開催。LINEプラットフォームの全体像を明らかにした。

　前編の「世界制覇をもくろむLINE――ベールを脱いだプラットフォームの全体像とは」では、その中でもLINEプラットフォームを統べる「Channel Gateway」とは何か、「LINEビジネスコネクト」の仕組みとは、通信やインフラをどのように高速化しているのかなどについてお届けした。

　前回の中編「LINEゲームの躍進を支えるゲームプラットフォームの概要とEsper CEPの活用例」では、LINEゲームを支えるプラットフォームの全体像と、オープンソースのリアルタイムモニタリング技術「Esper CEP」の活用例を紹介した。

公開座談会から見えてくる、LINEエンジニアの試行錯誤

　2012年6月のサービス開始以来わずか3年弱で、登録ユーザー数4億人を突破し、さらに成長を続けるLINE。その急成長の陰には、最新技術を駆使してサービスを支えるエンジニアたちの並々ならぬ努力があった。

　4月17日のLINE Developer Conferenceでは、イベントの締めくくりとして、LINEのiOS／Androidアプリ、サーバー、Webフロントエンドの開発を担うトップエンジニアが一同に介して、公開座談会「Fire Side Chat」が開催された。当日は、イベント専用の公式LINEアカウントも用意され、参加者の質問を受け付けた。今回は、その内容を紹介しよう。

　Fire Side Chatは、前編記事でLINEプラットフォームの全体像についての講演を行ったLINE 開発1センター LINE技術戦略室の田中洋一郎氏をモデレーター役に進められた。モデレーター以外の参加者は以下の通り。

【サーバー開発担当】
同社開発1センター LINE技術戦略室執行役員梁ヒチャン（Heechan Yang）氏
【LINEアプリ開発 Android担当】
同社開発1センター LINE技術戦略室堀屋敷勉氏
【LINEアプリ開発 iOS担当】
同社開発1センター LINE技術戦略室上野賢一氏
【Webフロントエンド開発担当】
同社開発1センターウェブサービス開発室 UITチームマネージャー福島英児氏

公開座談会「Fire Side Chat」の様子（左から田中氏、梁氏、堀屋敷氏、上野氏、福島氏）

ログ用のテキストからデータを再構成した「12月事件」

田中氏　LINEは2011年6月に提供を開始して3年弱で、4億ユーザーを突破しました。世界的に見ても、これほどの伸びを示すサービスはないのではないかと思います。まさに皆さんは、そのサービスを支えてきたわけですが、開発を進める過程では、二度と思い出したくないという出来事もあったのではないかと思います。まずはそこから話をお聞かせください。

梁氏　振り返ってみると、僕の3年はどこにいったんだと言いたくなるほど忙しい日々が続きました。サービスの急激な成長にもサーバーチームのわずかな要員で対応しなければならず、つらいこともいろいろありました。

　1つだけ紹介すると、サービスを開始した年の2011年12月にサーバー開発メンバーが「12月事件」と呼んでいる事態が発生しました。先ほどの講演（前編の「LINEにおけるストレージ拡張と処理の高速化の歴史」参照）でも紹介されましたが、ちょうどRedisクラスターを導入した直後のことです。

梁氏「20時間ほどかけて徹夜で作業を行った結果、ようやく事態を収拾できました。こうした事態は、もう二度と経験したくありません」

　当時はクラスターの技術はまだ未成熟で、ある日曜日の午後6時ごろに突然障害が発生し、Redisクラスターのノードのデータがまるまる1個分、マスターだけではなくスレーブも含めて完全に消えてしまいました。当時はクラスターの可用性を信じ切っていましたので、バックアップデータもありませんでした。

田中氏　何とも恐ろしい事態ですね。どのように対応されたのですか？

梁氏　障害発生後、すぐにサーバーチーム全員が集まって調査を行いました。その結果、ログ用のテキストファイルが辛うじて残っていることが分かりました。そこで、ログファイルから全てのデータストラクチャを再構成してリストアするコードを書き、実データを復元することにしました。

Androidアプリの容量／メソッド数制限に苦しむ

田中氏　今のはサーバーサイドの話でしたが、LINEアプリは直接ユーザーの目に触れる部分でもあるので、また違った苦労があったのではありませんか？

堀屋敷氏　LINEアプリでは、機能を追加していくと当然ソースコードもどんどん大きくなっていくのですが、ある時、Android版LINEで、クラスの容量とメソッドの数が制限をオーバーしてしまって、インストールできないという問題が発生しました。

田中氏　Androidのアプリにはクラスやメソッドに制限があるのですか？

堀屋敷氏　そうなんです。Androidアプリには、インストールするための制限があり、クラスの容量とメソッドの数を減らさなければならなくなりました。その結果、機能を追加するたびにリファクタリングを行ったり、コンパイラーが自動生成するメソッドをなくしたり、バイナリファイルを複数に分けて、実行時に読み込むように修正したり、といった作業を機能追加するたびに行うことになりました。

iOSアプリでサーバーの負荷テスト？

田中氏　なかなか制限の上限には達しないと思うのですが、それだけLINEの機能が多いということなんでしょうね。それでは、iOS版の開発で苦労された点はありますか。

上野氏　LINEの問題というよりも、僕の技術の未熟さが招いたことなのですが、1つ大失敗がありました。LINEには立ち上げるたびにいくつかの最新データを取りにいく処理があるのですが、その一つであるタイマーのリセットのタイミングにミスがあり、LINEを立ち上げるたびに毎回データを取りに行く処理が走ってしまう事態が発生しました。

田中氏　LINEを起動すると必ずリクエストがサーバーに飛ぶとなると、LINEの利用が増えるほどサーバーに負荷が掛かりますね。