LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

SREならば自分の持ち味を発揮できる。LINEの信頼性を支えるエンジニアの挑戦 

LINEで働くエンジニアに色々と話を聞いていく「LINE Engineer Insights」。LINEの技術組織で働く個々人に、何を重視して技術者としてのキャリアを歩んでいるのか、今LINEで何に取り組んでいるのか、今後実現していきたいことなどを聞いていきます。

今回登場するのは、LINEのコンテンツプラットフォーム CSI SREチーム ( Communication & Service Integration Site Reliability Engineeringチーム ) でSREとして活躍する加藤俊弥。彼は20名強のサーバーサイドエンジニアとともに、LINEスタンプや着せかえ、LINE STORE、LINEアプリのホームタブ・ウォレットタブなどといった機能の信頼性制御のためのエンジニアリングに取り組んでいます。

自らの強みを活かすためにSREのキャリアを選んだという加藤に、仕事において大切にしていることや今後の目標などを聞きました。

採用面接で感じたLINEエンジニアの技術力の高さ

──まずは加藤さんの経歴について教えてください。

2014年に新卒で株式会社ドワンゴに入社し、アプリケーションエンジニアとして、JavaやScalaでAPIを開発していました。業務の過程でRedisやMySQLをはじめとしたデータベースに興味を持ち、さらにストレージ装置を初めとしたインフラも構築・運用するようになりました。その後、株式会社KADOKAWA Connectedにてプライベートクラウドを管轄するマネージャーも担いました。

エンジニアとしてはWebサービスのAPI開発やDBA、インフラ管理を経験し、マネージャーとしては採用計画・事業計画の立案や組織制度の提案などを経験しました。こうした幅広い業務を、社会人になってから6年ほどの期間で経験しているキャリアは珍しいかもしれません。そして、2020年12月にCSIチームのSREとしてLINEに入社しました。

──転職を考えたのはなぜでしょうか?

英語力と技術力の双方でスキルアップしたい気持ちが強かったためです。前職も技術力を磨ける環境ではありましたが、今まで培った技術力を新たな環境で活かせるか試してみたい、という思いも大きかったです。

─それらの条件にLINEの環境がマッチしていたのですね。

そうですね。とても印象に残っているのは、採用面接が非常に面白かったことです。エンジニアの方々との面接でしたが、2時間かけてオンラインホワイトボードを使ってアーキテクチャについての議論をしました。あるアプリケーションをテーマに「自分ならばどんなアーキテクチャでそのシステムを構築するか」を討論したんです。「ここはRead heavyで局所性があるためキャッシュが効く、ここはステートレスにしてオンデマンドに計算した方が後々にスケールアウトしやすい、どんな監視項目を設定して、どうやってボトルネックをチェックし、負荷試験計画はどういったものを考えられるか」といった議論を、ひたすら掘り下げるかなり濃厚な面接でした。

また、私が現在所属しているCSIは英語の方が得意なメンバーが多く、コミュニケーションを主に英語でとっています。その点も自分の要望にマッチしていました。

自分の強みを活かせるポジションがSREだった

──加藤さんは選考段階でSREのポジションを希望されていたそうですね。なぜ、この職種を選ばれたのでしょうか?

私の強みは幅広い技術領域を総合的に見て、サービスの課題を解決できる点だと考えています。正直に言うと、ソースコードやIssueを頻繁に確認したり、リリースノートを追っているRedis以外の技術領域では、エンジニアとしての目立った技術力はないと思っています。つまり、特定の技術だけで第一線で活躍し、サービスに貢献し続ける力は乏しかったです。

ですが、これがデータ構造やSQL、アプリケーションの実装を確認しつつ、かつ費用を鑑みてインフラ改善や有償サービス導入なども選択肢にいれて検討するような、あらゆる手段を検討できるポジションであれば、私の今までの経験を掛け算のように活かせると考えました。

──それがSREだったということですね。現在の業務内容について教えてください。

私のいわゆるEmbedded SREとしての業務は、大雑把に言うとサービスの信頼性制御のために必要な、ありとあらゆるエンジニアリングです。新規アーキテクチャーのレビューやIaCの推進、既存のシステムのコスト・パフォーマンス・可用性・セキュリティの改善、障害訓練の企画と運営、ポストモーテムミーティングのファシリテートなど多種多様です。SRE専任のメンバーが私を含めてチームに2人と少ないので、作業の自動化・省力化を推進し、なるべくミスなく効率的に進められるように工夫しています。

──SREとして働くうえで工夫していることはありますか?

一番大変なことは、SREという分野に関する情報のキャッチアップや、そのノウハウのチームへの浸透だと思います。LINEには独自の文化やツールがあるため、他社のSREの事例を導入すれば必ずしもうまくいくわけではありません。「LINEならば、どういった方法で各種のノウハウを取り入れるべきか」について、常に考え続けています。

また、先ほどもお伝えしたようにSRE専任のメンバーは2人であるため、SREに関しての意思決定において、私の意思が強く反映されすぎてしまう可能性があります。そうならないように気を使っています。

他の工夫としては、とにかくチーム内でオープンに立ち回るようにしています。積極的にサーバーサイドエンジニアの各メンバーとコミュニケーションをとっていて、もしかしたらCSIチームのSlackチャンネルで一番発言しているのは私かもしれません(笑)。提案や調査結果の共有などもなるべく高頻度に、そしてわかりやすく行い、周りをなるべく巻き込んでいます。

SREは非常に少人数のチームであり、何をやっているのか、何をやりたいのかを積極的に共有していかなければ、いざというときにサーバーサイドエンジニアの協力を得られないためです。

信頼性を制御するため、できることはなんでもやる

──入社してからさまざまな業務に携わってきたと思いますが、特に印象に残るものはありますか?

チャレンジングだったと感じている業務は、障害訓練を企画してCSIのサーバーサイドエンジニアたちと一緒に実施したことです。CSIの開発には「何かの障害が起きた際、対応できるか・できないかが各エンジニアのスキルに依存している」という課題がありました。そこで障害訓練を実施し、対応に慣れているエンジニアの作業内容を他のエンジニアが見て学ぶことで、チーム全体の障害対応力を底上げする方針にしました。

この訓練では負荷のジェネレーターを用いることで、過負荷によって障害が起きた状態を擬似的に再現させます。そして、障害対応に慣れているエンジニアがWeb会議ツールで画面共有をしつつ、オペレーションをしました。スキルの高いエンジニアがどんな作業をしているのかを他のエンジニアが知ることができ、非常に学びの多い取り組みになりました。チームメンバーからは「ぜひ定期的に開催してほしい」という声が挙がっています。

他にはRedisクラスターの改善を行いました。あるプロジェクトでサーバー移設が必要になったため、Redisのデータベースの中身を調査してみました。基本的に、Redisにデータを格納する際には有効期間を設定するので、時間が経てば揮発してデータが一定量以上は増えません。しかし、そのデータベースではデータが単調増加し続けており、Redisが260GBほどのメモリを使っていることが判明しました。もちろん監視はしており、これでも危険水準には至っていませんでしたが、思わぬ時限爆弾でした。

これはおかしいと思い調査したところ、あるデータをRedisに格納する際に、有効期間の設定をしていないことがわかりました。そして、この事例が厄介だったのは、単純に有効期間を設定すれば解決する問題ではなかったことです。対象となったシステムでは、キャッシュのデータをRedisに、永続的に残すデータをMySQLに格納しています。Redisのキャッシュが存在しない場合は、その情報をMySQL側から取得する一般的な構造です。

しかし、Redisに格納するデータ1つあたりの情報量が非常に大きいデータ構造だったため、それが揮発するとMySQLに対して一気にアクセスが増え、データベースの負荷が高くなることがわかりました。そこで、その負荷を軽減できるように、Redisで扱うデータ構造の変更も行いつつ、サーバーの移設のプロジェクトを推進しました。これらの施策がうまくいき、その結果としてRedisが使用するメモリは260GBから大幅に削減できて、70GBくらいで安定するようになりました。

こうした事例からもわかるように、基本的には「信頼性を制御するため、できることはなんでもやる」というスタンスで仕事に取り組んでいます。

LINEで培ったスキルは必ず今後のキャリアのプラスになる

──LINEで働き続けている理由について教えてください。

まずは自分自身の強みを生かせるところです。先ほど複数の領域を総合的に見てボトルネックを解決できる点が自分の強みであると話しましたが、LINEでSREとして働く過程で、その長所を発揮できていると感じます。

また、これも入社理由と関係していますが、企業としてのダイバーシティを大事にしており、かつ働いているだけで英語だけでなくコミュニケーションのスキルが向上することです。日々の業務の中で、会話をする際にもドキュメントを読む際にも英語に触れます。そこで感じるのは、英語の方がわかりやすいこともあるし、日本語でもわかりにくいことがあるということです。それがおそらくコミュニケーションやドキュメンテーションのスキルなのだと実感しています。また、メンバー同士がリスペクトを持って仕事をしているのも良い点です。マネージャーや同僚のエンジニアたちの言葉の節々から、それが伝わってきます。

それから、LINEで培ったエンジニアリングのスキルは、間違いなく今後のキャリアにとってプラスになること。私が業務で解いている課題は、非常に難易度が高いです。そして、それらの課題はLINE固有のものではなく、他のサービスでも起こりうるようなものばかりです。そのため、LINEで磨いたスキルを、次に働く場所でも必ず活用できると考えています。

──エンジニアとして働くうえで大切にしていることはありますか?

やはり一番は、先人たちや既存のシステムをリスペクトすることです。SREという業務の特性上、いわゆるレガシーなアーキテクチャやコードに触れることが多いです。それらのシステムを「良くない状態だ」と非難するのではなく、リスペクトを持ち、なぜそういった状態になっているのかを冷静に把握することが重要だと思っています。

その次が、リスペクトするけれど、でも積極的に改善するという腕力です。これは、やり遂げる力と言い換えてもいいかもしれません。システムをより良い状態に保つには、アーキテクチャの刷新やコードのリファクタリングが必須です。そして、そうした改善を行う際には、必ずシステム移行の“過渡期”が生じます。

過渡期が長く続くのはあまり良い状態ではありません。認知負荷の原因にもなりますし、予測可能性の障壁にもなるからです。だからこそ、強い意思と腕力で過渡期を終わらせることが重要だと考えています。

──今後、業務の中で挑戦したいことを教えてください。

GoogleやNetflixなど、SREのケーススタディを積極的に情報発信している有名企業のプラクティスは、参考にできる要素がたくさんあります。それらの知見を取捨選択しつつ、LINEにマッチする形で導入したいです。その次の段階として、自分たちのSREの事例をケーススタディとして外部にアウトプットしたいです。そうすることで、日本国内のSRE界隈を盛り上げる一助になればいいなと思っています。

私たちのチームでは、一緒に働くメンバーを募集しています。

少しでもこれらの取り組みに興味があれば、気軽にお声がけください。