Reliabilityを高めるために最短距離を走る　LINEのコンテンツプラットフォームSREの仕事

Redisのヘビーユーザー

加藤俊弥氏：加藤から「コンテンツプラットフォームのSRE」についてご紹介したいと思います。

まず私の紹介から失礼します。2014年に株式会社ドワンゴに入社しまして、niconicoのバックエンドのエンジニアをやっていました。

アプリケーションのエンジニアとして、ScalaやJavaなどを書いて、その後Web API GatewayのチームのリードやOAuthチームのリードを担当し、Redisのヘビーユーザーでもあったので、RedisのDBAも兼任していました。。

Redisのほうからキャリアが広がって、MySQLやElasticsearchのDBaaSを作り、結果的にディスクストレージのほうまで面倒を見たほうがいいだろうということで、Block StorageやFile Storage、Object Storageまで見て。

そこまで見たら、じゃあプライベートクラウド全体じゃない？　となって、2019年の一昨年まではKADOKAWA Connectedという、角川グループの会社でDBaaSやストレージなどプライベートクラウド全体を見ながら、P/LやB/Sも含めた予算、採用計画などもやっていました。

今のLINEの Communication ＆ Service Integration室のSREとして入社したのは、ちょうど10ヶ月ほど前ですね。アプリケーションエンジニアやDBAの経験などがあったので、それを活かして信頼性向上のためにエンジニアリングをやっています。

サーバーサイドのエンジニアと一緒に働く

サービスのスコープから話していきたいと思います。このコンテンツプラットフォームのスコープは、すごくわかりやすいところで言うと、LINEのスタンプや着せかえ、絵文字など、あとはWebのLINE STOREというサイトも私たちですね。

また、LINEアプリで一番左にHOME、一番右にWALLETという名前のタブがあると思うのですが、その2つも私たちが管理をしています。例えば、今みなさんがLINEでスタンプなどを送信していただくと、その所有権を判定する処理が私たちのサービスで行われています。

このスタンプなどのチームの運用体制ですが、サーバーサイド開発がいて、企画や運営の方がいて、開発UITと呼んでいる主にJavaScriptやHTMLを担当しているチームがいて、デザイナーがいて、ネイティブアプリにはクライアントサイド開発がいて、あとはQAで品質保証のチームがいます。SREはこのサーバーサイド開発に所属をして、サーバーサイドのエンジニアと一緒に働いています。

開発の拠点は、先ほどの佐藤からも東京の四谷オフィスの案内はありましたが、LINEとしては、LINE Fukuokaも合わせて主に日本だと2拠点。福岡と東京にいて、それぞれ私たちのチームだと、エンジニアだけで福岡に9人、東京に16人という体制で開発をしています。ただ、このコロナ禍ということもあり、私も入社してから10ヶ月間でオフィスに行ったのが、たぶん全部で2回程度。ほぼリモートワークで、転職してからずっとリモートワークで働いています。

またこのコンテンツプラットフォーム、スタンプなどのチームは非常に多国籍のチームでして、日本やアジア圏だけでなく、アフリカやヨーロッパ、アメリカ大陸など、いろいろな国からのメンバーがおり、日本語がまだ苦手な方もいるし、逆に私などはそうですが、英語がまだまだ苦手な方もいます。そういった、ちょっとバリエーション豊かなメンバーで構成されているチームです。

コミュニケーションの方法も気になるかもしれませんが、それは後ほど話したいと思います。

Reliabilityを高めるための最短距離は何なのか

これが技術スタックです。まずInfrastructureという意味だと、プライベートクラウドは「Verda」と呼ばれているものを使っています。このVerdaについては、あとで萬治さんからVerdaのSREとしてセッションがあると思うので、そちらを楽しみにしていただければと思います。

Verdaのチームが、VMと物理マシン、またはKubernetesなどをInfrastructure as a Serviceとして提供していて、私たちはそれを利用しています。VMなどであればAnsibleとAWX（Ansible Towerのアップストリームプロジェクト）。あとは、内製ツールを使ってプロビジョニング&デプロイを行っていたり、KubernetesであればArgoCD、DroneCIでGitOpsでデプロイを行っています。

Jenkinsは、主にコードスタイルのチェックや、Pull Request Builderを使ってCIが回っています。モニタリングやアナリティクスは、いわゆるオブザーバビリティの3要素、トレーシングでZipkin、ログでElasticsearch、Fluentd、Kibana、いわゆるEFKスタック、長期間の分析が必要な時はHadoopを使っています。

メトリクスでは、Prometheus、Pushgateway、Grafanaなどを使って、メトリクスの収集やアラーティングをしてモニタリングしていますね。ミドルウェアはかなり大雑把な括りなのですが、MessageBusとしてKafkaを使っているのとWebサーバーとしてNGINX。データベースはキャッシュはRedis、検索はElasticsearch、MySQLとMongoDBはスケールアウトやトランザクションあたりで使い分けています。

言語は、JavaとKotlinが中心ですね。ただ、使い捨てのスクリプトなどであれば、PythonやNode.jsで書いたり、各エンジニアが慣れているスクリプト言語を使うこともあります。フレームワークはSpring Bootが中心で、ArmeriaというLINEのOSSやRxJavaを使って、リアクティブプログラミングで開発されています。

スタックとしてはちょっと多いように見えますが、先ほどのVerdaもそうですし、DevOpsのチームがJenkins、DroneCI、AWXを提供してくれたり、モニタリングのチームがPrometheusを提供してくれたりデータプラットフォームのチームがHadoopを用意してくれています。

また、DBAの方がMySQLやRedis、MongoDBをプロビジョニングして管理してくれています。基本的には社内で使えるもの、もちろんサービスレベル的にも機能的にも使えるものがあればそれを積極的に使っていって、もしなければ自分たちで用意します。たとえばArgoCDは自分たちで管理をして使うようなかたちで行っています。

ですので、SREの特徴としては、企画の方やDBAの方、データサイエンティストやDevOpsのチーム、そういったいろいろな社内のロールの方々に、ワンホップで直接アクセスして、信頼性、Reliabilityを高めるために最短距離で改善する、という仕事をすることが多いです。

例えばDBがちょっと詰まっていて、スロークエリが出ているという時に、クエリをチューニングするというのは当然やったほうがいいのですが、「そもそもこの仕様、スペック、ビジネスがイケてないよね」であれば、企画の方に相談して変更したり、クライアント側で「この画面の時にプリロードすればユーザー体験が良くなるんじゃないか」と考えたりします。

Reliabilityを向上させる目的のために、最短でかつ今後負担にならない、負債にならないようなものを選ぶのが、主にSREの、私たちのロールかなと思っています。

グローバルな「あけおめ」LINE

1つちょっと特徴的な課題を具体的に紹介したいと思います。「あけおめ」LINEですね。ここにも書いてあるとおり、負荷の規模は、5分前からその瞬間になった時に3、4倍になって、一気にそり立つ壁のように増えるというのが非常に特徴で、かつ1年に1回の特大イベントのためキャパシティプランニングがとにかく難しいです。1年間に行われたアーキテクチャ変更や、その間にリリースされた新機能で負荷特性が大きく変わっていることが、ままあります。

かつ年末年始のキャンペーンで、LINEの公式からのキャンペーンも当然ありますし、公式アカウントの方々の企画で、ユーザーのアクセスパターンが大きく変わっちゃうこともあって、キャパシティプランニングがかなり難しいのが、非常に大きな課題であります。

こちら、深掘りして話すと時間が足りないので、TechTalkなどのタイミングがあれば、ぜひお話したいなと思うのと、もしもっと具体的に聞きたければ、カジュアル面談などでお声がけしていただければと思います。

コンテンツプラットフォームSREの魅力

そんな私、10ヶ月程度ではありますが、コンテンツプラットフォームのSREに入って魅力に感じたことを、ここで紹介していきたいなと思います。まず1つ目、いの一番なのですが、技術的な課題が非常に難しくておもしろいというのがあります。リアルタイム性が求められていて、大規模で。しかも日本だけじゃなくてグローバルなんですよね。

例えば、「あけおめ」LINEにしても日本時間00時に日本でピークになりますが、そのあと台湾が1時間後にピークになって、日本時間で午前2時にインドでピークになって、みたいな。日本を耐えてもまだ安心できない、そういったところで、グローバルなおもしろさはけっこうあるかなと思います。

あとはチームワーク。心理的安全性と書いてもいいのかもしれませんが、日本のオフィスで福岡と東京にいるだいたい25、6人のエンジニア集団で、本当に良い議論をしながら課題を解決できるところが魅力だなと思っています。

コミュニケーションについては、基本英語です。ですが第二外国語としての英語話者も多いという印象を私は持っています。求められる英語力の水準はそんなに高くなくて、それこそGitHubで、OSSを開発する程度あれば十分業務はできるなと思っています。日常会話のジョークなどは、ちょっとなかなか難しいことはあったりしますけど。

またリモートワークなこともあり、特にSlackとかConfluenceのやり取りが多いため、reading/writingができればlistening/speakingはそこそこでも、ぜんぜん苦もなくできるんじゃないのかな、と私は思っています。私自身すごく英語が苦手なので、佐藤のセッションで紹介にあった語学学習の福利厚生を活用しています。日本語話者じゃない方は日本語の勉強をしている方も多いようです。

最近行った障害訓練

もう1つ、環境ではなくて活動面でいうと、裁量が非常に大きいと思っています。改善のための提案からエンジニアとして実際に手を動かすところまで、さらにそこからSLOを設定して、その結果をさらにフィードバックループを回して、またもう1回やれるところとか。そういった、課題の発見・設定から解決まで大きな裁量を持って最後まで遂行できるところが、非常に自由度が高くて魅力的だと考えています。

当然なのですが、本当に何でも自由とかではなりません。説明責任や議論をしながら、良い意味で裁量を持って進められるなと思っています。

また、CI/CDやモニタリングの改善など、当然そういうものはどんどんエンジニアリングとしてやっていきますが、それだけじゃなくてチームの改善、例えばポストモーテムや障害訓練も行っています。たとえば、ポストモーテムを主導して、「こうしたほうがいいんじゃないのか」といった提案をどんどん受け付けたり、「なんでこうなっているの？」みたいな素朴な疑問、そういうものを大事にして、ファシリテーションしていますね。

1、2ヶ月に1回障害訓練をやっていますが、特にここ最近で行った障害訓練は、「この日のこの時間ぐらいに開発環境で障害が起こるので対応してください」だけ案内して、私がその時間になったら、ロードジェネレータで負荷をかけるスクリプトを流して高負荷でダウンさせたり。そうしたらみんなが、ワラワラ集まってきてスケールアウトしようとしたり、スロットリングしようとしたり、このIPアドレスからのアクセスを弾こうなど、私が攻撃者となっていろいろ障害訓練をやっています。

最後にOnCallですが、非常に気になるところかなと思います。コンテンツプラットフォームのチームでいうと、OnCallにSREとSWEの区別はなくて、今のチームではSWEとSRE全員が1つのチームで、OnCallの輪番を回しています。実績としては2、3ヶ月に7日程度の頻度でOnCallが回っているような状態でいます。

以上、コンテンツプラットフォーム、スタンプなどのチームのSREについて加藤が紹介しました。

このポジションにご興味がありましたら、下記のページからぜひ応募してください。