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

Verda Platformに対する Site Reliability Engineering に関わる業務を担当しているチームを紹介します

LINEの開発組織のそれぞれの部門やプロジェクトについて、その役割や体制、技術スタック、今後の課題やロードマップなどを具体的に紹介していく「Team & Project」シリーズ。今回はLINEのプライベートクラウドであるVerdaに対するSite Reliability Engineering(以下SRE)活動をしているチームを紹介します。

Verda Reliability EngineeringチームのPark Youngwoon、山田英樹、Kang Moon Joongに話を聞きました。

Verda Reliability Engineeringチームの皆さん

―― まず、自己紹介をお願いします。

Park: LINEのプライベートクラウドであるVerda について、SRE活動をミッションとしているVerda Reliability Engineering Team(以下VRE)のマネージャーをしています。VREチームは日本、韓国の2拠点に跨がるチームで、その両方に対してマネジメントを行なっています。

山田:VREチームでシニアエンジニアとして働いています。クラウドインフラの開発・運用には数多くのレイヤの技術が使われていますが、その中でも特にサーバやOSといった比較的低レイヤな部分に対するSREをメインに実施しています。具体的には、OSレベルのトラブルシューティングやクラウドリソースのキャパシティ管理、物理リソースの調達に関する業務改善などがメインミッションです。

Kang: 2019年度の新卒として韓国側のチームにジョインしました。入社前は大学の研究室に勤務していて、その経験を活かしてVerda全体のシステム監視の開発、運用に取り組んでいます。

―― みなさんがLINEに入った理由を教えてください。

Park:前職ではパブリッククラウドサービスを提供する会社でIaaS領域の開発・運用のマネージャーとして働いていました。ただ、ユーザとの距離感が離れていると感じていたのと、IaaS領域以外での開発経験を積みたかったので、社内の開発者に幅広いレイヤのサービスをプライベートクラウドとして提供しているVerdaのチームにジョインすることを決めた、という感じです。

山田:私は前職では企業の研究所に所属していて、主にグループ企業向けのクラウドサービスの研究開発に取り組んでいました。研究所という立ち位置だと開発から運用まで一括して実施することが難しかったので、ユーザに近い位置でサービスの開発・運用に取り組めること、求められる技術スキルと自分の専門領域がマッチしていたことからVerdaのチームに入ることを決めました。

Kang:大学での専攻がクラウド関連で、韓国内でそれを活かした仕事ができる会社としてLINEには注目していました。

特にVerdaのSREチームの業務は自分の専門と一致していたので、インターンを経て入社を決めたという流れです。

インターンでの経験で印象的だったのが、課題の発見から解決までの取り組みを自分主導で進められたことです。自分の取り組みに対してチームメンバーからのフィードバックも多くあり、積極的な姿勢で働けそうだと感じたことが入社を決めたキッカケになりました。

左上から時計回りに、シニアエンジニアの山田、マネージャーのPark、エンジニアのKang

―― LINEで働くやりがいを教えてください。

Park:大規模なインフラに対して、信頼性という大きなテーマで積極的に挑戦できる環境であることがやりがいに繋がっています。

VerdaはIaaSの他にもコンテナベースのPaaSやDBなどのマネージドサービスも提供しています。それぞれのサービスに対してSRE活動をするためには専門的かつ深い知識と経験が求められる一方で、サービス横断的な運用体制の改善や共通システムの開発などでは知識や経験の幅が重要になってきます。

逆に言えば比較的自由に動ける立場で色んな種類のチャレンジができる環境なので、そういうところにやりがいを感じています。

山田:自分の作った仕組み、もっと言えば書いたコード1行が大規模なインフラ環境全体に影響を与えるような仕事が多く、自分の関わった仕事が大きなインパクトになって表れるところにやりがいを感じています。

また、ユーザが社内の開発者なので詳細なフィードバックを得やすく、それが自ずと開発や改善の速度の向上に繋がってると感じます。インフラという分野でVerdaほど開発サイクルが短いプロダクトはそうそう無いのではないでしょうか(笑)

―― チームの構成・役割などについて教えてください。

Park: チームは日本・韓国の2拠点に分かれていて、日本で5名、韓国に3名の合計8名で構成されています。

チームの役割ですが...複雑なので図で説明しますね。

今のVREで実施している業務は、大きく以下の3種類に分類できます。

Customer Reliability Engineeringの部分はチーム全員で持ち回りで取り組んでいますが、IaaS領域に対するReliability Engineeringと監視、デプロイシステムの開発についてはチーム内でおおよそ役割分担ができている、という感じです。

IaaSの話をすると、VMが6万台以上、BaremetalやHypervisor、Storageとして使われている物理サーバーは2万台に迫る数がサービスインされていて、これらの運用にかかるコストは膨大なものです。このコストを自動化や安定化によって下げていくことはVREの重要なミッションになっています。

また、監視、デプロイの対象となるサービスやそれらが使うリソースもかなりのボリュームなので、方式をなるべく統一することで管理コストや開発者側の機能実装コストを下げようとしています。

社内のユーザーに対するサポートやSolution Architect的な活動は一貫してVREが一次対応を実施しています。対応コストを下げるために特定のトピックについては直接開発者にメンションを飛ばす機能を開発したり、「VMに接続できない」といった問い合わせに対して自動で接続確認を実施する仕組みを作るなど、技術的なソリューションも積極的に導入されています。まだまだチャレンジの余地がある分野です。

山田:上記の分類に対する役割分担が個人単位でしっかり決まっている、というわけではなくて、複数の領域に跨って仕事をしているメンバーがほとんどです。

例えば私はBaremetalのセットアップ手順の改善やリソース監視手法の開発・運用など複数の領域にコミットしています。役割分担というよりは、それぞれのメンバーの得意分野がどこにマッピングされるか、という捉え方の方が正確ですね。

Kang:私もStorageサービスに対するSREとサービス横断的な監視基盤の開発・運用の両方にコミットしてますね。サーバメンテナンスやサービス障害の通知を改善するプロジェクトを通して、CRE的な活動にも積極的に取り組んでいます。

―― 利用技術・開発環境について教えてください。

Park: VerdaのユーザとVerdaの開発者、そして私たちSREの関係を簡単に図にするとこんな感じです。

この関係図の中で私達が責任をもって開発、運用してる部分は「オペレーション自動化の仕組み」「CI/CD」「Monitoring」の3つです。ほんとはもっと複雑なんですけど、あくまでインタビュー記事なのでシンプルに分類してます。

CI/CDから軽く解説しますね。サーバーの構成管理、サービスデプロイなどで広くAnsibleを使っています。独自モジュールを開発して可読性や安定性を改善したり、AWXなどの実行基盤を導入することでイベントドリブンなAnsible実行を実装するなど、結構ヘビーに使っていると自認しています。

デプロイの実行、履歴の管理には現在のところJenkinsを使っていますが、マニュアルオペレーションが多いので新しい要求の整理と代替手段の検討を進めているところです。

オペレーション自動化ではPythonを使うことが多いです。簡単なスクリプトを書いたり、複雑なオペレーションを単純化するためのインターフェースを備えた中間サービスを開発してユーザや開発者に提供しています。

ユーザからのリクエストは基本的にSlackで受けているので、botをうまく使ってよりユーザが親しみやすいインターフェースを提供できるように改善を進めているところです。

Monitoringについてですが、メトリクス管理にはPrometheus、ログ管理にはElasticsearch + Kibanaと割とスタンダードな技術選定をしています。特にPrometheus周りはサービスプロセスやミドルウェアのより詳細な状態を監視できるように独自exporterを積極的に開発しています。開発にはGoやPythonを使っています。Web APIを持つサービスについてはOpenAPI(swagger)によるAPI specをベースにPrometheus形式のメトリクスを取れるようにしていて、様々なサービスに導入されています。

インシデントの情報はAlertmanagerを経由してPagerDutyという外部のインシデント管理・通知サービスに集約しています。また、同じAlertmanagerからAWXにwebhookを発行することで自動復旧playbookを実行するなど、イベントドリブンな復旧フローの整備を進めています。

山田:オペレーションを円滑に進めるためのツールの実装にはBashやPythonを使うことが多いです。特にPythonはOpenStackやAnsibleと相性がよくて使いやすく、使用頻度が高いですね。各サービスのCLIを用いてBashでスクリプトを実装することもありますし、なんだかんだコーディングスキルが求められますね。

―― 今のチーム課題と課題解決に向けた取り組みについて教えてください。

Park:IaaS領域では、Baremetalの使用率が高いことが大きな課題の1つです。

社内には性能の上限や計算能力の安定性などを重視するユースケースが多く、VMへの移行があまり進んでいません。VMとBaremetalは様々な点で管理方式に違いがあり、特にBaremetal関連の運用コストは高いので、Baremetalの使用率の高さが全体的な運用コストの高止まりに繋がっています。

現在、性能要件の厳しいユースケースに対応できるようリソースのIsolationを厳密にしたVM typeを開発したり、VMを効率よくスケジュールすることでVM1台あたりの利用コストを下げるようなプロジェクトを通してユーザへBaremetalからVMへの移行を促そうとしているところです。

監視、デプロイの領域は全体的にまだ取り組みが始まったばかりという段階なので、課題になってないところの方が少ないくらいです。サービス横断的な監視システムの改善、デプロイの仕組みを効率化するなどの仕事は最終的なスコープがとても大きいので、効果のありそうなところから一歩ずつ進めている状態ですね。

個別のサービスに対するSRE活動についても、仮想化やネットワークなどの深い専門知識が必要になることからVREでカバーできてないところが多いです。他の業務との兼ね合いもあるので、どう進めるか迷っています。

バランスをとって進めるにはマンパワーが足りないと感じるので、採用活動に力を入れてる段階です。

山田:他の部署と連携しなければいけない業務について非効率な部分があるため、改善に取り組んでいます。

例えばサーバの増設ではデータセンターや構成管理DBを管理している部署との連携が必要なのですが、ラック管理、サーバ設置、資産登録、運用ツールへの登録、BIOS設定、RAID設定、自動OSインストーラへの登録、プライベートクラウドへの登録、ユーザ管理...という一連の業務フローにおいて、各タスクの担当部署が細かく分かれており、業務の切れ間が存在しているのが現状です。個別のタスクはおおよそ自動化されているのですが、タスク間の連携がうまくとれておらず、この状態では効率化にも限界があります。

現在、一連の業務フローとタスク間の連携を整理し、これらを全て繋げて自動化するプロジェクトをVRE主導で進めており、課題の解決を目指しています。

自動化という文脈だと、チーム間でのワークフローの整理以外にも日々発生するオペレーションを定型化・自動化する活動は日常的に実施しています。ただ、改善活動によってオペレーションにかける時間を圧迫すると業務が滞ってしまうので、そのあたりのバランスをどうとっていくかは課題の1つです。

Kang:クラウドサービスの開発・運用をする以上、物理マシンやネットワークで発生するトラブルの対処も我々の仕事です。

このインシデントはどのようなクラウドリソースに影響があるのか、どのユーザ・LINEサービスに影響が出るのかを、我々がきちんと把握して適切にユーザに連絡することは重要なことであり、よりユーザにとって分かりやすい通知方法を考えることもVREのミッションの1つです。

今はまだ連絡手段のUXが不十分だと感じているので、韓国のメンバーを中心に改善のためのプロジェクトに取り組んでいます。

―― 今後のロードマップを教えてください。

Park:我々は将来的にLINEのすべてのインフラをVerda化することを目指しています。

そのため、LINEの開発者に信頼をもってVerdaを使ってもらうための改善・開発の優先度が高いです。

短期的なロードマップとしては、

  • 現在開発中のSaaSホスティングサービスのSLO/SLA定義からシステムの可視化、信頼性を担保するためのプロセス確立
  • Healthcare/Fintechなどの特別な要件を持つサービスに向けた共通インフラ基盤を提供するためのインフラ設計から運用設計
  • 物理サーバーの管理コスト削減・最適化のためのOCP(Open Computing Project)の導入
  • 共通モニタリングシステム開発・プロセス確立
  • Admin管理ツールのプラットフォーム化
  • 開発プロセスの共通化(CI/CD)
  • CRE/SA Activityを強化するための体制作り

について取組むつもりです。

長期的には、スケーラビリティ周りの改善に取り組んでいきたいと思っています。LINEのサービスやインフラの規模が現在の10倍、100倍になってもそれをVerdaで管理できるようにすることが目標です。

―― 最後に、Verda Reliability Engineeringチームに興味を持ってくれた人にメッセージをお願いします。

Park:Verda Reliability Engineeringチームは、LINEの開発者がVerdaを信頼して利用できるようにすることをミッションとしています。

LINEは様々なサービスを抱えており、それらに使われるインフラの信頼性を高めることは最終的に数え切れないほどのユーザの利益に繋がるので、とてもやりがいのあるミッションです。

ミッションの背景や規模感に惹かれる方、様々なサービスや専門領域に跨ってSREというロールで働くことに魅力を感じる方に是非来ていただきたいと思ってます。

チームメンバーもクラウド人材一辺倒ではなく、様々なバックグラウンドを持つ人が集まっています。興味のある方は気軽に話を聞きに来てもらえると嬉しいです!

山田:インフラを見たいしコードも書きたい!という方には最適だと思います。最近はインフラエンジニアと言えばクラウドを使う人を指すことが多いと思いますが、クラウドを作る人になりたい方は是非Verdaに来てください。

Verda Reliability Engineeringチームではメンバーを募集しています。 

ソフトウェアエンジニア / SRE / Private Cloud Platform