LINE Engineering
Blog
RedisConf18登壇レポート
LINE Messenger ServerのStorageチームでRedis関係の様々な開発を手がけています。
こんにちは。LINEのRedisチームのJongyeol Choiです。LINEでは、各サービスで様々なストレージシステムを使用しています。たとえばメッセージングサービスではRedis、HBase、Kafkaといったオープンソース・ストレージシステムをたくさん利用していますが、中でも私が担当しているのはRedis関係の開発です。その業務の一環として今年4月26日、米サンフランシスコで開かれたRedisConf18に発表者として参加し、「Redis at LINE, 25 Billion Messages Per Day」と題して発表を行いました。今回の記事では、発表の準備から発表への反応、そしてカンファレンスの雰囲気などをお届けします。
RedisConfとは？
RedisConfは、RedisLabs社主催の公式カンファレンスです。同社はオープンソースRedisの生みの親であるSalvatore Sanfilippo氏の所属会社で、今はRediseというエンタープライズバージョンの開発が行われているそうです。RedisLabsは技術カンファレンス「RedisConf」を毎年開催することで、Redisユーザの裾野を広げ、様々な会社やサービスをまたいで知見が共有されることを目指しています。
私はRedisチームの一員として去年もこのカンファレンスに参加したのですが、当時は一般聴衆としての参加でした。そのときの関心事は、Redisの使いこなし方、そして他社、他サービスでRedisがいかに利用されているかを調べることでした。期待通り、カンファレンスに参加して各社におけるRedisの使い方とそのノウハウを学ぶことができました。さらに、いくつもの発表を見聞きしているうちに「自分たちのケースを発表するのも面白いかも」ということに気づいたのです。というのも、LINEのユーザ数や使用するトラフィックはどこの発表内容と比べても非常に高い水準だったからです。サーバー開発分野では、ユーザ数やトラフィックが多いほど、発生する問題の範囲も広がります。サービスを安定的に維持しながらさらに高めていくには、より精巧かつ多様な技術とノウハウが求められます。そこで、LINEのスケールやノウハウに関する発表は世界中の開発者にとってきっと興味深い内容になるはず、と考えたのです。
Call for papers、そして発表に向けた準備
アメリカでは、多くのITカンファレンスが4~6月に開かれます。RedisConfも毎年4~5月と、開催時期はだいたい決まっています。私は去年、つまり2017年の12月にRedisConf18のCall for papersを見かけました。カンファレンスなどでの発表者を募集することをCall for papersといいますが、申し込みさえすれば全員発表できるわけではありません。正確な倍率こそ分かりませんが、審査を経て申請者の一部だけが発表者に選ばれます。
Call for papersの応募期間は2017年12月いっぱい。多くの開発者からLINEのユースケースを期待されていることを考えると内容のことはさほど心配にならなかったのですが、英語で発表することにはプレッシャーを感じました。英語でしゃべるなんてまだ自信がない。それでも、時間をかけて準備すれば内容はきっと伝わるはず、とCall for papersに応募することになりました。テーマは「LINEメッセージングサービスでのRedisのユースケースおよび様々なノウハウ」と定め、abstractを作成しました。申込フォームにはabstract以外にもいくつか項目がありましたが、中でも目立ったのは「Diversity」という項目。特定の性別、人種に限定せず発表者構成の多様性を追及しようということで、申請者が女性、有色人種、あるいは障がい者なのかを尋ねています。多様性が尊重されているという印象を受けました。
そして12月末。発表申し込み承認を知らせるメールが届きました。嬉しい気持ちを一方に抱えながら、数ヶ月に渡る長い準備に取りかかることになりました。1セッション当り45分ですので、5~10分のQ&A時間を除くと、発表時間は35～40分という計算になります。発表日は4月25日か26日のいずれかになる予定。実際の準備が始まったのは1~2月になってからのことです。時間を見つけては発表資料をまとめ、チームメンバーを前にリハーサルを行って、周りの意見を参考に内容を修正していきました。話のスムーズな展開、伝わりやすさという観点から、社内のテクニカルライターにも協力してもらいました。与えられた発表時間を考慮してスクリプトを用意し、サンフランシスコに着いてからも発表前日まで録音しながらリハーサルを繰り返し行いました。私の発表はカンファレンス2日目に予定されていたので、発表前にカンファレンスの雰囲気や会場を事前に確認することもできました。
カンファレンス初日
RedisConf18の日程は4月25日(水)と26日(木)の2日間。登録した参加者は1,000人強で、約60件の発表が2日間にわたって6つのカンファレンスルームで行われました。下の写真は会場のPier27の前景です。RedisConf18と記された垂れ幕が下がっているのが見えますね。
いくつかノベルティをもらって、さっそく1階のExpo Hallへ。カンファレンスの全般的な情報やスケジュールが閲覧できるアプリ「Redisconf」がiPhone用、Android用の両方で提供され、自分のセッションも以下のようにアプリから確認することができました。
会場にはところどころ自由に持っていけるようステッカーが置いてあるスペースがありました。そこで私も許可をもらい、持参したLINEステッカーを並べてみたのですが、多くの方から「The bear is cute!」と喜ばれ、わずか1、2時間で品切れになるほどの人気ぶりでした。
Keynoteスピーチ
カンファレンスの幕開けとなったのはRedisの生みの親であるSalvatore Sanfilippo氏によるkeynoteスピーチ。まだリリース前のオープンソースRedis 5.0に関する内容で、5.0が近くリリース予定とのこと、そしてその主な機能、たとえばStreamsなどに関する説明へと続きました。彼のスピーチが終わると、他の発表者たちが順番に登壇し、企業向けバージョンのRediseなど様々な内容を紹介してくれました。「Joel on Software」という書籍の著者で、StackoverflowのCEOとして知られるJoel Spolsky氏が登壇し、インタビューも行われました。
1日目のセッション
Keynoteスピーチ終了後、各セッションは6つのカンファレンスルームに分かれて行われました。最初に参加したセッションはSalvatore Sanfilippo氏による「The Design of Redis Streams」。先ほどのスピーチで触れたRedis Streamsについてより詳細な説明を聞くことができました。従来のRedisをキューとして利用する会社やサービスはかなり多く、その際はList型にBLPOP、RPUSHなどのコマンドが用いられます。ただ、RedisのListをキューとして使うには機能として不十分なところも多いのでKafkaを使ったりもします。LINEでもニーズに合わせてRedisかKafkaを適宜使い分けしています。ところがRedis 5.0には、このようなキューなどの用途にも合うように、Streamsという新しいデータタイプとコマンドが追加されるとのことです。まだリリース前ではありますが、Redisが他のデータベースより速いことを考えると、有効に使える部分は多いかも知れません。
午前中のセッションが終了すると、何台ものフードトラックが並び、参加者には美味しいランチが振舞われました。
午後にもいくつかのセッションに参加しました。中でもSlackの「Scaling Slack’s Job Queue Using Kafka and Redis」と、Lyftによる「Redis at Lyft: 2,000 Instances and Beyond」の2つのセッションは興味深いものでした。業務用メッセンジャーとして広く使われるSlackではRedisをキューとして使用していたようですが、いくつかの制約や信頼性の問題からKafkaとRedisを併用することになったそうです。同じメッセージング分野なだけあって、Slackの事例はLINEの事情とだいぶ重なるところもあれば相当違う部分もありました。Lyftから来た発表者は、去年のRedisConf17でも発表したDaniel Hochman氏。LyftはEnvoy Proxyというオープンソースを展開している会社ですが、オンデマンド配車サービスも実施しています。タクシーの運転手と乗客をマッチングするサービスですね。乗客のニーズにタイムリーに対応しないと意味がないこの手のサービスの特性から、信頼性よりは反応速度に重きを置いているところが印象的でした。他にもいくつかのセッションに参加したのですが、翌日自分の発表が予定されているというプレッシャーから、話の内容になかなか集中することができません。初日のプログラムがすべて終了すると、ビールと軽食が提供される交流会にも参加せず、私は緊張した気持ちでホテルに戻り、リハーサルを続けました。
2日目、ついにXデー到来
いよいよ発表当日。聞きたいセッションはいくつもありましたが、午前中もホテルでリハーサルをしていて他のセッションには参加できませんでした。2日目も前日同様、6つのカンファレンスルームに分かれて様々なセッションが同時に行われました。私の発表は午後2時、場所はVan Nessホールと予定されていました。
そして発表の時間。準備を整え、マイクを付けて壇上に立ちます。ありがたいことに、多くの方に参加いただいていました。左下の写真は発表前の会場内の様子。右は自分です。
発表が始まりました。ここにその内容を簡単にご紹介しておきましょう。LINEではメッセージングサービスのためにRedisやHBase、Kafkaを使用しています。毎日250億件以上のメッセージを届けるために運用しているRedisノードは10,000以上に達します。多くの会社でRedisクラスタリングのためにプロキシ方式が採用されています。ところが、メッセージングサービスはレスポンス時間が命ですので、LINEではプロキシ方式ではなくRedisをクライアント側でシャーディングする自前のRedisクラスタを主に利用しています。シャードの情報はZooKeeperに格納し、各アプリケーションでその情報を同期します。Redisクラスタで特定のマスターサーバーがダウンして自動フェイルオーバーが発生した場合、あるいはホスト交換などの状況では、Cluster Manager Serverというモジュールでこの情報を管理します。たくさんのRedisノードを秒単位でモニタリングするために、ScalaとAkkaでRedis Cluster Monitorというモジュールを開発、利用しています。他にも、Redis 3.0に新たに追加されたオープンソースバージョンの公式Redis Clusterを導入する中で経験した試行錯誤などいくつかの問題を共有し、非同期RedisクライアントであるLettuceの導入経験も共有しました。
発表動画と資料
私の発表動画とスライドは、以下のように公開されています。ご興味のある方、ぜひご確認ください。
Q&A
あっという間に所定の発表時間は終了。様々な国・地域から参加しているバラエティ豊かなバックグラウンドを持つ開発者、同じような悩みを抱えている開発者や他のセッションの発表者、そしてOSSコミッターなど、多くの方からたくさんのご質問をいただきました。Q&A時間が終わって、動画収録が終了しマイクがオフになってからも質問が相次いだので、別の場所に移動してやり取りを続けました。
以下にその質疑応答の内容を共有したいと思います。
Q. Dual WriteとRead HAの説明についてですが、Kafkaで書き込み処理をリトライすると時間はどれくらいかかりますか？
書き込み処理のリトライにおいて今はアプリケーションサーバーと同じホスト上で動作するローカルRedis queueを利用していますが、これもKafkaへの移行を検討しています。Kafkaにすると数百マイクロ秒程度のRedisよりやや時間はかかりますが、それでも数ミリ秒くらいです。HBaseに書き込みする場合は、マルチバージョンですので多少の遅延は許されます。
Q. Redis operation burstingが瞬間的に起こったりすると、Automatic bursting detectionでそれを検知することは可能ですか？
1秒ごとのINFOコマンドの結果に基づいてバーストか否かを判断していますが、その後からMONITORコマンドを送るので、瞬時にバーストしてしまうと検知できないときもあります。ただ、多くの場合、バースト中盤以降の一部は検知できるので、それを元にどのコードと関係しているか追跡することができます。それから、CPUが100%のときにMONITORコマンドを送ると状況をさらに悪化させかねないので、CPU使用率が特定のしきい値を超えた場合にはautomatic bursting detectionを行うことはありません。
Q. Hot keyとreplicated clusterのところで、読み込みパフォーマンスの向上については理解できましたが、書き込みパフォーマンスを向上させる方策はあるんでしょうか。
サーバ1台で処理できるリクエストの数は限られています。同じキーに対して書き込み性能を向上させることは難しいので、キーのデータを複数のキーに分散させるなど、ビジネスロジックの設計を見直す方向でアプローチしています。
Redis Cluster 3.2のused memoryが大きい理由は何ですか？
Redis Cluster 3.2は、キーとスロット番号をマッピングするのにSorted Setを使います。ところがクラスタにキーが多いと、マッピングにメモリをたくさん費やされてしまいます。そのためLINEで使用する一部のクラスタでは、メモリ使用量がスタンドアロンRedisの2倍に達しています。Redis Cluster 4.0はこのマッピングにradix treeを用いることで3.2よりは使用量を抑えていますが、それでも依然、スタンドアロンRedisよりは使用量が大きいほうです。
Asynchronous Task Processorでバックグラウンドで書き込み処理を行うと、RedisとHBaseとの間にinconsistencyが発生する恐れはありませんか？
一時的にinconsistencyはありえますが、ReadHAにおけるほとんどはRedisで読み込んでいて、HBaseで読み込む場合は多くありません。あと、LINEはメッセージングサービスですので、瞬間的なinconsistencyよりはavailabilityの方がもう少し重要といえます。
懇親会
カンファレンス2日目の発表まですべて終了すると、後は交流の時間です。参加者の多くは、セッション終了後もすぐ会場を離れることなく、あちこちで話に盛り上がっていました。その様子をすべて写真に収めることはできませんでしたが、裏手に設けられた食堂スペースや、目の前に海が広がる屋外などでビールを飲みながら会話している人をたくさん見かけました。夕方には発表者だけが集まる立食スタイルの小さな懇親会が行われました。他の発表者との会話を通じて技術を共有したり、LINEを紹介したり、いくつか新しいアイデアを得たりと、自分にとってもとても有意義な時間でした。発表に至るまでの数ヶ月に渡る長い道のりはこれで終わりです。
おわりに
世界中の開発者と知見を共有し、質問しあい、ディスカッションするのは楽しい経験です。さらに今回は、海外のカンファレンスにただ聴衆として参加するのと、発表者として参加するのとでは色々な面で明らかに違う、ということを実感できた時間でもありました。多くの開発者からの真摯なご質問を受け、アドバイスしあうなど、大いに刺激になったと思います。発表前はただ準備するのが大変で終わりが見えない感じでしたが、その結果はなんとも甘美なものでした。英語も発音がどうしても気になっていたのですが、人種や出身地など、参加者のバックグラウンドがまちまちで彼らの発音もこれまた千差万別。もっとも、自分の発音が聞き取りやすいものだったとはいえないでしょうが、それでもLINEの発表内容自体が興味深いものだったからか、開発者たちは発音などあまり気にせず熱心に聞き入ってくれました。結局、重要なのは技術的な内容だったんですね。私たちのチームはこのようにより多くの内容を共有しようと絶えず取り組んでいます。そしてその道のりを共に歩んでいけるストレージエンジニアを日本と韓国で募集しています。ご興味のある方は、下記採用ページをご確認ください。以上、最後までお読みいただきありがとうございました！
LINE Messenger ServerのStorageチームでRedis関係の様々な開発を手がけています。