参加レポート: LINE Developer Conference (Infra Day)

佐々木大輔

2014.04.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

4/15(火)に開催されました、LINE Developer Conferenceに参加してきました！

本イベントはメッセンジャーアプリでお馴染みのLINE株式会社さんが、そのバッググラウンドで行われている技術的取り組みや運用の工夫についてお話頂けるというものです。私が参加した4/15(火)のインフラをテーマにした回と、4/17(木)のプラットフォームをテーマにした日の、2日間に渡って開催されます。

本イベントは参加枠はそれぞれの日毎に150人・合計300人だったのですが、何とインフラ回だけで460名の応募があったとのこと。二日間合わせた全体では800名強の応募があったそうです。それだけ注目度が高い企業であるということですね。

会場は渋谷ヒカリエにあるLINE株式会社さんのカフェスペース。普段はカフェとして使われているとても広いスペースをセミナー会場として使われていました。LINEさんのオフィスは全体的に綺麗で立派でした！

また今回は参加者全員にお土産がありました。ありがとうございます！

レポート

イベントとしてはスライドの撮影禁止とのことでしたので、後日スライドが公開されることも恐らく無いのだろうと思います。このレポートで少しでも皆さんにイベントの雰囲気をお伝え出来たらと思います！

LINEについて by CTO 朴さん、池邊さん

まず初めにCTOの朴さん、池邊さんから、LINEの現状とそしてこのイベントで伝えたいことについてお話を頂きました。LINEはつい先日登録ユーザー数が世界で4億人を突破したとの報道がありましたが、メッセージ数としては毎日100億件程度の流量があるそうです。世界展開としてはブランチオフィスが6カ所と、更に連絡用のオフィスが9カ所あり、開発オフィスは日本、中国、韓国、台湾に分散して設置されているとのこと。また固定的なオフィス以外に「LINE遠征隊」という各国を回って課題を聞き出したりトラブルシューティングをするチームがあるそうです。

お二人とも、キーワードとして強く「グローバル」を打ち出されていました。そしてそのグローバルな市場で戦う為に高い品質を保つことを大事にしており、その為の施策を今回のイベントで伝えたいとのことでした。

上記のLINE遠征隊のようなユーザに近い場所でサポートするチームがいることももちろん、後述する各エンジニアさんの様々な施策でも、品質確保という点で試行錯誤されていることが伝わるイベントだったと思います。

LINEサービスのシステム運営 by 佐野さん

システム運営チームのマネージャである佐野さんから、LINEのシステム運営についてのお話がありました。

LINEではサービススタートからこの2年間でユーザ数もメッセージ数も増加の一途を辿っており、合わせてサーバ台数やサービス数も増え続けているそうですが、システム運営に携わるメンバーについては入れ替わりがあれど人数としては増えていないそうです。これはシステムデリバリでPlug and Install(kickstartやWindows Deployment Serviceなどを使った自動インストール)の仕組みを作り、サーバにLANケーブルを接続して電源を投入するだけでセットアップ出来るようにしていることが人数を増やさずに運営していけている一つの理由とのことでした。

そんなLINEサービスのシステム運営の中で発生した問題として3つの事例をご紹介頂きました。

1つはIDC内部でのConnection Timeoutの発生について。LINEのシステムではインターネットを介した通信だけでなくサーバ間通信も多く発生する仕組みとなっているそうですが、そのサーバ間通信が行われるIDC内部のL2スイッチでパケット廃棄が多発する自体が発生したとのこと。トラフィック量としてはL2のスループット性能以下であり問題無くスイッチング出来るはずだったのですが、原因としては瞬間的にトラフィックがバーストした際にL2スイッチのバッファがオーバーフローしパケットが廃棄されてしまっていたそうです。なおこの現象は連続してトラフィックが発生している場合では問題が無く、バースト時のみに発生するとのこと。なかなか切り分けが難しいトラブルですね。LINEのようなメッセージサービスは性質上バーストが起こりやすく(例えばイベントで何かが起きた場合、サッカー日本代表がゴールを決めたとき等。またオフィシャルアカウントはフォロワーに一度に数十万人に対してメッセージを送るため瞬間メッセージ流量が跳ね上がるそうです)、対策としてバッファサイズの大きなL2スイッチに変えたり、バーストが発生しやすいようなサーバは独立したネットワークに分離するなどを行われたそうです。

2つ目はIDC空間の不足。これは後述のネットワークレイヤのセッションでもあったのですが、LINEさんでは基本的に物理サーバで構成していて、サーバ台数だけで5桁(万単位)の台数があり、そうするとIDCの物理的スペースを食いつぶしてしまいサーバを設置する場所が無いという事態が発生しているそうです。LINEサーバのクラスタの仕組みで最も多く使っているのはApache HBaseだそうですが、経験則として1000台以上のクラスタ構成にすると性能が出ず、またサーバ台数を増やしていくとその分故障の可能性が増えるため運用コストが増加してしまいます。そのためサーバ台数を減らす施策として、サーバのスケールアップによる集約と、そして段階的に仮想化を行っているところとのこと。スケールアップとしてはCPUやメモリなど様々な方策がありますが一番ボトルネックとなったのはDisk I/Oで、ここは検証した結果最もIOPSが高かったPCIE-SSDを導入することで高いパフォーマンスが発揮出来たとのこと。また仮想化についてはVMware vSphereを使われており、1物理サーバに対し10VMくらいを割り当て、現在は数千台くらいのGuestOSが動作しているそうです。

3つ目は運営上の問題。上述の通りメッセージングサービスはバーストトラフィックが発生しやすい性質がありますが、予測可能なイベントについては事前にサーバを増加するなどの対策を行っているそうです。しかし今年の元旦、所謂「あけおめ」メッセージでは一部トラブルが発生したとのこと。当初は予測通り通常の数倍のトラフィックが発生し問題無くサービス提供出来ていたものの、突然メッセージ送信が不安定になったそうです。原因はLINEのバックグラウンドで使われているRedisの一部Shardに負荷が集中し応答が無くなったこと。根本的にはそのShardでRedisとNIC割り込みが同じCPU coreを使っており処理が出来なくなったことが原因だったそうで、応急処置としてtasksetコマンドでRedisが使うCPU Coreを別のものに割り当て、現象が解消されたとのこと。これもなかなか経験しないというか、規模が大きいからこそ発生するトラブルですね。

佐野さんのお話は、LINEというグローバル規模で提供しているサービスならではのトラブルとその対処の事例として、とても面白かったです。

LINE DBシステムの高可用性について by 崔さん

データベース運営チームの崔さんからはLINEサービスの特徴とDB部のFail Overの仕組みについてお話頂きました。

LINEはユーザが爆発的に増加しており、そのユーザ増に備える様々な施策を行っているそうです。なおDBは複数のシステムを使っているそうですが、その73%はMySQLとのこと。大半ですね。パフォーマンスとしてはSASからSSDに切り替えることで性能対策としているそうです。

DB冗長化構成のFailOverの仕組みはMulti-Master Replication Manager for MySQL(MMM)を使って行っており、これは障害発生時にMasterNodeに割り当てられていたVIPをSlaveNodeに割り当て直すことでFailOverをする仕組みだそうです。またこのMMMをカスタマイズして利用しており、1つのMMMで複数台モニタできるようにしたり、FailOver時には外部スクリプトをキック出来るようにしているとのこと。またReplication Check機能はレプリケーションの遅延でフェイルオーバーが発生してしまうため機能自体を削除したそうです。

もう一つはN-BaseというLINEが独自に開発した仕組みで、無停止でShardを追加するというもの(すみません、ここがよく聞き取れなかったのですが、MySQLでShardingをされているということなのでしょうか)N-Baseの仕組みとしては、レコードをShardに振り分けする際にhash演算を行ってグループIDという独自の情報を加えて、管理サーバ(MGMT)がグループIDとshardのマッピングを行っているとのこと。Shardを追加したり障害などでShardが削除されたりした場合にはMGMTがグループIDトShardの再マッピングを行ってレコードのShardへの再振り分けを行うそうです。

LINEさんのような大きなシステムで、大半がMySQLで動作されているというのは少し驚きがあったのですが、今回お話頂いたような様々なカスタマイズやノウハウによって高い可用性を実現されているということが分かって面白かったです。

LINEサービスのネットワークインフラ取り込み事例 by 三枝さん

元オンプレネットワークエンジニアの僕が最も楽しみにしていたのがこちらのお話でした。ネットワーク運営チームの三枝さんからのお話です。

システム運営チームのセッションでもありましたが、やはりユーザ数の増加に伴ったサーバ台数の増加により、IDCのスペースが足りなくなっているというのが課題として挙げられていました。

困っていたこととして、ネットワーク構成上ブロードキャストドメイン(L2ドメイン)が広くなっており、サーバのNICがdown/upしてMacアドレステーブルがフラッシュされてしまったタイミングで1Gbps超のデータが発生する(unknown unicast flooding)問題が発生していたそうです。対策としてはL2ドメインを狭めることとして、元々は集線スイッチ単位でL2ドメインを構成していたものを、エッヂスイッチ単位でL2ドメインが分かれるように構成を変更したそうです。またシステム構成上インターネット向けの通信だけでなくサーバ間通信も大量に発生するため、各集線スイッチからインターネットに出る線とは別に集線スイッチ同士を繋ぐ線を用意し、通信を分離する施策も行ったとのこと。またL2ドメインを細分化したことに合わせて、これまでL2DSR方式で行っていたロードバランサをL3DSR(DSCP)に変更したそうです。

データセンタについては、高効率・高密度をIDCの選定基準としたとのこと。そしてこのような高スペック・高価格のIDCを有効活用する方法として、「サーバを詰めれるだけ詰める」という方針を取ったそうです。具体的には特注した定格24kVAで100口の電源ポートを持つ51Uのラック(！)を使い、フルフルにサーバを詰めているそうです。またラック毎にサーバ以外にスイッチも配置するのですが、サーバの廃熱の影響を受けやすいため、これも特注のスイッチダクトを作成し、ラック内でサーバとスイッチのエアフローを分離出来る仕組みとしたとのこと。

なお、セッション後のQAで出たのですが、ラックの裏の配線についてはかなり気を使っているそうで、電源ケーブルは可能な限り短くカットし、LANケーブルは特注ラック内に用意した配線スペースを通すようにしているとのこと。懇親会でネットワーク運営チームの方にこの辺を深くお聞きしたのですが、サーバ自体は既製品の同一機を使っているそうで、全てのサーバで電源ポートやネットワークポートの場所が同じになっているため、配線がしやすいそうです。確かに別々のサーバを同一ラックに乗せると、あるサーバは右側からケーブルが出るけどあるサーバは左側からといったように、ケーブルの差し込み口自体がバラバラになってしまい、カオスな配線になってしまいがちです。配線の綺麗さはイコールメンテナンス性の高さに繋がりますので、様々な考慮をされているのだなと感じました。

続いて、ワールドワイドな部分でのネットワークについてのお話でした。グローバルに展開しているサービスであるため海外でも同様に高い品質を保つ必要がありますが、海外ではインターネット回線の品質が高くない場合も多く、海外利用者の品質確保が課題とのことでした。そこで品質が低下するポイントを調査したところ、一つは通信キャリア同士の相互接続ポイント、そしてもう一つは日本と海外という物理的な距離に起因するものであることが分かったそうです。

そこで解決策として、各通信キャリアとLINEの直接的なパスを作り、キャリア同士の相互接続ポイントでの品質低下を極力回避すること、加えて海外にもサーバを配置し、出来るだけ利用者に近い位置にあるサーバに接続してもらうようなアプリケーションの仕組みにしたとのことでした。

このために世界中にLINE拠点を作り、拠点間は孤立が発生しないように専用線で接続してリングトポロジを構成しているそうです。またその上でMPLS+Pseudo Wireを構築し、物理トポロジに捕われないネットワークを構成しているとのこと。アプリケーションの接続サーバの選択は接続キャリアや電話番号、GeoIPなどを使って静的に割り当てているそうですが、将来的にはグローバルロードバランサの導入も検討中だそうです。この辺はグローバルサービスだからこその取り組み事例ですね。

LINEはスマートフォンに特化したメッセンジャーアプリなのですが、特にリアルタイム性を重視しているとのことで、アプリケーションとしてはほぼTCPセッションを張りっぱなし(！)になっているとのこと。このためロードバランサでのセッション数制限がボトルネックになってしまい、セッションテーブルのエージング時間調整など施策を行ったそうですが、結果的にロードバランサではセッション管理をさせない方針とし、Stateless SLBに切替を行ったそうです。Stateless SLBはセッションテーブルでは無くハッシュテーブルを使って負荷分散をする仕組みになっており、セッション数が制限にならなくなるとのこと。Stateless SLBの振り分け方式としては、サーバの台数の増減に従って全体のハッシュ値を再計算するものや増減した対象のみを再計算する方式があり、LINEではユーザ数が多い事から全体の再計算が入るとサーバ増減に関連しないユーザにまで影響があるため、後者の増減分のみを再計算する方式を取っているそうです。今後はOpenFlowなど他の仕組みも検討したいとのことでした。

このネットワーク運営チームさんのお話は僕ももちろんたくさんの人が強く興味を惹かれたようで、懇親会でも多くの人がネットワーク運営チームのメンバーさんにご質問をしていました。あの51Uラックはやはり衝撃的でしたね。本当に面白いお話でした。

まとめ

以上、僕のメモから参加レポートを起こしました。LINEさんはサービスとしても企業としても有名ではありますが、こういったシステム構成や裏側のお話というのは今まではなかなか情報が開示されていなかった部分かと思います。このようにグローバル規模でかつ大量のユーザが利用しているサービスで、どのような品質確保のための施策を行われているのかがお聞き出来て、とても良いイベントでした。

またこういう機会があれば是非参加したいです。LINE株式会社さん、本当にありがとうございました！