- インタビュイー
-
Verda SREチーム マネージャー 萬治渉
![Verda SREチーム マネージャー 萬治渉]()
昨今，
LINEの多数のサービスを支える
- ――まず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の概要
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チームである我々も， 何種類もあるストレージについて， 個別に課題の発見や改善をするといった世界にはしたくない。それぞれのチームの要件をきちんと吸収できるものが作れるのであれば， それを僕らが作ってみんなにそれを使ってもらうのが効率的です。これは監視用のストレージのみならず様々な部分で発見できる種類の課題だと思っています。
からの記事と詳細 ( LINEのインフラ基盤「Verda」のビジョンとSREが果たすべき役割とは - Gihyo Jp )
https://ift.tt/3BKm20L
0 Comments:
Post a Comment