LINEのインフラ基盤「Verda」のビジョンとSREが果たすべき役割とは

インタビュイー: Verda SREチームマネージャー 萬治渉

昨今、ソフトウェアエンジニアリングを活用し、サービスの運用効率化や信頼性向上に取り組む考え方や方法論である「SRE」（⁠Site Reliability Engineering）が広まりつつあります。LINEでも2019年にSREに取り組む専門チームが発足しており、同社のプラットフォームである「Verda」で提供するサービスの運用業務の効率化などに取り組んでいます。そのSREチームを率いるマネージャーである萬治渉氏に、SREチームが発足した背景や現状の取り組みなどについてお話を伺いました。

LINEの多数のサービスを支える「Verda」

――まずVerdaの概要について教えてください。

萬治：LINEでは一般的なパブリッククラウドを使う方針は基本的には採らず、大部分のインフラを自社で保有し運用しています。このインフラのプラットフォームがVerdaで、現状では74,000台以上のVM（Virtual Machine）と30,000台以上のPM (Physical Machine = Baremetal Server）が実行されています。

当初、VerdaはOpenStackベースのIaaSとしてスタートしました。物理サーバをVerdaというプラットフォームで抽象化することで、LINEの各サービスがVMやPMといった形でリソースを使えるようにしたのです。

その後、アプライアンスのロードバランサを内製のソフトウェア型ロードバランサに置き換えたり、MySQLをマネージドサービスとして提供したりといった拡充を重ねてきました。さらに現在では、VerdaマネージドなKubernetesのクラスタを提供する、Kubernetes as a ServiceもVerda上で広く使われています。

このようなVerdaで提供するサービスの開発において、最近ではインフラのリソースを提供すること以上に、インフラリソースをどう使ってもらうかを意識して機能開発することに軸足を移しています。それにより、サービスを開発するエンジニアが意識しなければならない領域を小さくすることが目的です。

この連載で、Verdaで提供しているNATサービスについてのインタビューがありましたが（「Verda」――LINEが独自に開発したNATサービスの裏側⁠）⁠、それが提供される以前はLINEのDC外のアドレスと通信するサーバに逐一グローバルIPアドレスを割り当てる必要がありました。しかしユーザが管理するサーバ台数が増えてくると、リソース量の削減や申請のリードタイムを減らすためにユーザ側でプロキシサーバやNAT機器を用意してグローバルIPアドレスを共有するケースが発生するなど、ユーザ側がさまざまなことを考えなければならない状況でした。しかしVerda上でVM とシームレスに結合するNATサービスを提供したことで、このようなケースでユーザが考えるべきことを減らすことができました。

同様にユーザが自らVerdaで調達したVM上にスクラッチでKubernetesの環境を構築しようとすると、それなりの手間がかかるほか、それを運用するコストも発生します。しかしVerda側でKubernetesクラスタを払い出すようにして、ユーザが自由に使っていいという世界を創ったので、ユーザはKubernetesそのものの運用についてリソースを割くことなく、より運用負荷が低く信頼性の高いサービスの実装を進めることができるようになりました。

このように、Verdaは単にインフラのリソースを提供するだけでなく、ユーザがそれをどう使いたいのか、そのインフラリソースを使ってどういったものを作りたいのかといった部分に踏み込み、ユーザが考えるべきことを減らすなど、もっと便利に使ってもらえるようなサービスを提供しています。

Verdaに潜む課題とSREによる解決策

――Verdaが現状で抱えている課題には、どういったものがあるのでしょうか。

萬治：IaaSやロードバランサ、Kubernetes、MySQL、Elasticsearch、RedisといったVerdaで提供しているマネージドサービスは、それぞれの開発チームが個別にデプロイや監視などといった運用を行っているケースがほとんどです。今後Verdaの規模が拡大すれば、たとえばそれらのサービスのメトリクスやログを保存するためのストレージやサーバを確保したり、管理するための仕組みを作るのに大きな手間がかかるようになるでしょう。こうした作業を各開発チームが個別に行うのは、Verda全体として見たときに大きなコストの無駄になります。これはVerdaにとって大きな課題であり、SREとして対策を考えています。

――この課題に対して、どのような方針で解決を目指しているのでしょうか？

萬治：回答の前提として、一般的なSREとVerdaにおけるSREの比較と違いについて説明させてください。

SREの一般的な概念は、担当するサイト（システム）の信頼性を担保することを目的に、システムのデザインや開発プロセス、運用の改善などを担当するエンジニアと言えます。Verdaにおいてもその概念は変わりません。

ただ、LINEのサービス全体に関わるVerdaというプロダクトを対象とするため、細かな仕様決めや役割の分担を言語化することが難しいポジションでもあります。つまり、1つのプロダクトに対してどこまで担当するかという深さの決め方、また、（⁠Verda上で動く）プロダクトに対して、一人ひとりがいくつのプロダクトを担当するのか、あるいは、複数人で横断的に担当するのかという、横の幅の広さの決め方が、いわゆる1つのサイト（システム）を扱うSREと比較して複雑なロールになっています。

私たちはその複雑性に対処するために、それぞれの開発チームとSREの責務を分担する方針を取っています。基本的にはデザインや実装、デプロイなどの各プロセスについて開発チームが実施責任を持ち、SREチームはそれぞれのチームの活動について課題を分析して開発プロセスや運用を効率化するためのVerda横断的なソリューションを開発して各チームへの導入をリードする方針です。

先ほど挙げた課題については各開発チームで似た課題を抱えていたことから、まさにそのような方針に沿って課題解決に取組むことで大きな効果が期待できると考えています。

具体的な戦略は、SREチームがサービスを動作させるための共通プラットフォームを開発し、Verdaの“⁠中の人⁠”たちがサービスを開発・運用するときに利用してもらうというものです。あらかじめ定められたポリシーや使い方に従ってプラットフォーム上でサービスを開発すると、メトリクスやログが自動的に信頼性の高い大容量ストレージに保存され、それぞれの開発チームのエンジニアはそれがどこでどのように運用されているのかを気にしなくても済むというストーリーです。

それによって、モニタリングのデータがどういう状態を指し示しているのか、それに応じてどういったアクションを取る必要があるのかといった部分に注力してもらえるようにしたいと考えています。

――メトリクスやログがサービスごとにバラバラに開発される背景には、どういった理由があるのでしょうか。

萬治：たとえばMySQLのチームが管理しているメトリクスやログは、ストレージチームが提供しているオブジェクトストレージを使って保存しても構わないでしょう。ただ、そのオブジェクトストレージのメトリクスやログを自身のサービスに保存してしまうと循環が発生してしまうため、彼ら自身にとって本当に望ましいモニタリングができません。

また、サービス間の依存関係についても考える必要があります。例えば、Verdaのロードバランサを使ってストレージ基盤のAPIサーバへのアクセスを分散している場合、ロードバランサの監視データをどこに保存するべきか悩んでしまいます。開発チームは、メトリクスやログを保存する基盤に自分たちのロードバランサをなるべく使いたくない。もしロードバランサに障害が起きてダウンしてしまうと、その直前のメトリクスやログを参照できないといった状況に陥りかねないためです。Verdaのサービスには他のVerdaサービスに依存して構成されているものが複数あるので、似たような罠がたくさん転がっています。

そのため、Verdaの外部にあるストレージに保存することを検討したいのですが、LINE社内のプロダクトはほとんどがVerdaのサービスを利用して構成されています。そのため、Verdaの外部にある社内プロダクトを使おうと思っても、Verdaとの依存関係を慎重に排除しなければならず、かえって手間がかかってしまうことがあります。

こうした背景から、目的は同じでも開発チームごとの要件の違いによって、それぞれ異なる構成の簡易的なストレージを独自に管理している状態になっています。ただ、Verdaを俯瞰する視点から見ると、同じようなことをそれぞれのチームがやっているのでリソースの無駄があると言えます。またSREチームである我々も、何種類もあるストレージについて、個別に課題の発見や改善をするといった世界にはしたくない。それぞれのチームの要件をきちんと吸収できるものが作れるのであれば、それを僕らが作ってみんなにそれを使ってもらうのが効率的です。これは監視用のストレージのみならず様々な部分で発見できる種類の課題だと思っています。

SREチームが解決に向けて取り組む課題

――SREチームの取り組みについて教えてください。

萬治：正式にSREチームが立ち上がったのは2019年7月です。私が入社したのもその頃でしたが、当時は具体的に何をしなければならないといった課題設定が決まっていませんでした。前身となったオペレーションユニットの業務であるVerdaに対する社内からの問い合わせへの対応や物理機器のマネジメント等が主要な業務で、チームでシステムの信頼性を上げるための活動をしていくのはまだまだこれからという状況の中、私を含めた何人かのエンジニアが草の根的にSREの領域に踏み混んだ活動をしていたんです。

その活動の中でAPI監視やメトリクス監視の仕組みを作ったところ、前述のようにVerdaの各チームがそれぞれ実施している運用周りの活動を一般化して集約することに大きな価値があるという議論が起こりました。そうしてSREという広いテーマからミッションを絞って活動していくことが決まったという状況です。

SREチームで達成したい大きなテーマの1つは、Verdaのサービスを開発する各チームがそれぞれ持っている運用関連の負担を可能な限り減らすことです。運用周りの活動を具体的に分類していくと、汎用化が可能な程度の大きさの取組みの集合として構成されていることが分かってきます。監視を例に挙げると、必要なデータを取得するための仕組みの管理、データを保存するためのストレージの管理、そして意味のあるデータに加工する作業などに分解できます。

たとえば必要なデータの取得であれば、ほぼすべてのサービスはHTTPのインターフェイスを持っており、それぞれのAPIのパスやメソッドについて成功率や失敗率、レイテンシといった値はどのサービスでも監視したいデータです。そのようなデータを取得するための仕組みをチーム個別に開発するのは無駄が大きいため、共通のAPI監視の仕組みを作り、各サービスが簡単に利用できるようにするための環境の整備を進めています。

他にもデプロイや自動テスト、ユーザ向けのドキュメンテーションなども同じように分類を進められます。少しおもしろいのが、彼らが自分たちのサービスのコントローラーやデータプレーンをデプロイするために利用するインフラの管理を大きな負荷だと感じているところです。インフラプラットフォームを作っているという前提ならではの難しさがありますが、その難しさを丁寧に分類していくことでかなりの部分について一般化が可能だと思っています。

障害対応のフローを整備することも、SREにとっての重要な使命です。Verdaがダウンしたときに、それをいち早く検知し早急に復旧させることは、Verdaを利用している社内の人たちにとっての信頼性の要素の1つです。

その部分の信頼性向上を考えたとき、早急な障害検知と復旧のほかにも、障害が起きないようなテストとデプロイの方法を考える、あるいはサービスの根本的なデザインの見直しや品質の向上によって障害の発生を防ぐなど、いくつかの軸があります。それらすべてに対して、SREという立場でVerda全体に向けてどういう活動ができるかを考えています。

LINEのSREチームが求める人材像

――SREチームとして、今後取り組みたいのはどういったことですか。

萬治：今後はSREチームからVerda全体に向けて何らかの取り組みを進めたり発信したりするだけでなく、それぞれの開発チームからSREチームに対してニーズを伝えるといった活動も重要になると考えています。ただ現状では、役割として確立していないこともあり、そうした活動のリードを取れるメンバーがまだまだ足りません。そのため、開発チームの中にSREというロールで働いてもらえる人材を配置することを検討しています。

――SREチームで働く人材に求められるスキルについて教えてください。

萬治：VerdaにかかわるSREには、サービス横断で対応する共通SREに加え、今後は先ほどお話した各開発チームの中で働くSREも置きたいと考えています。両者に求められるスキルは当然異なりますが、求める人材像で共通しているのはリーダーシップを持っている人ですね。このリーダーシップを具体的に言うと、何かを決めてそれを進められる人です。

何かを決めるにあたって、それに必要な情報を100％集めることができれば苦労はありません。現実はそうではなく、情報が揃っていない、不確定な状態でどちらかに決めることが求められることが多いです。そのようなときにちゃんと決断して行動できるのがリーダーシップだと考えています。まずいったん決める、それで仮に失敗したとしても構わない。反省を取り込みつつ前に進んでいくことが大切です。そういったマインドで物事を決め、プロジェクトを進めることができる人と一緒に働きたいですね。

――SREとして働いていて、おもしろさややりがいを感じるのはどういった部分でしょうか。

萬治：SREとしての1つ1つの取り組みが、Verdaチーム全体、ひいてはLINE全体に大きな影響を与える点はおもしろさを感じられる部分ではないかと思います。

たとえばメトリクスとログを保存するストレージ環境は、気合を入れれば1人で2カ月ほどで作れるでしょう。これを特定のチームに導入することで、そのチームでメトリクスやログの管理に携わっているエンジニアの稼動を半分にすることは十分現実的に可能です。さらにVerdaのすべての開発チームに導入していくことまで考えると、もっと大きな稼働の削減につながっていきます。このように導入早々に効果が出そうかつ将来的にもっと大きいインパクトを出せる活動が色々考えられる立場なので、おもしろさややりがいを感じられる仕事だと思います。

また自由度が大きいこともSREの魅力です。ほかの開発チームと比べて、SREチームのミッションは信頼性という比較的抽象的な言葉で定義されています。発生する課題の種類も様々で、それぞれの課題解決のためにこれまた色々なアプローチを採ることが可能です。そのため、解決のインパクトが大きい問題をどういう思考プロセスで解決していくのかという抽象的なところから具体的な手段までを自分たちで1から考えられて、さらにそのようなチャレンジをたくさんすることができる環境であるというのは、エンジニアにとってすごく魅力的ではないでしょうか。

――最後に、今後の展望について教えてください。

萬治：LINEにはさまざまなサービスがあり、そのほとんどはセキュリティにおいて高い基準が設定されています。特に金融や医療などの領域では、監督官庁が策定したガイドラインなどによってサーバーインフラのレイヤから厳しい要件が設定されています。そのような要件が厳しい領域にもVerdaがインフラリソースを提供していくために、要件の整理と機能開発がすさまじいペースで進められています。

こうした流れが加速していくと、LINEのすべてのサービスでVerdaを使う、オールVerda構想の実現もどんどん近付いてきます。SREチームには、オールVerda化によってさらに拡大するプラットフォーム規模のスケーラビリティの問題を解決していく取組みが求められていくでしょう。

これに応えるためには、SREチームが作る内部サービスについてそれを見越した「具合のいい設計」をしていかなくてはいけませんし、将来的にそれらの仕組みを運用する体制についてもスピードを損なわない程度に事前に考えておかなくてはいけません。つまり、拡大していくVerdaの規模に対応しつつ、その先まで見据えて準備を進める、つまりは足元を固めることが重要になると思っています。今僕らの目の前にはそういうチャレンジが一杯転がっている状況なので、一緒にそれを楽しんでいけるエンジニアがたくさん集まるといいなと思っています。