こんにちは、早稲田大学 修士1年の井上(@musaprg)です。8/17から約6週間、技術職 就業型コースのインターンシップに参加しました。
私は、Verda室のVerdaプラットフォーム開発Kチームという部署に配属され、Verda Common Proxy(VCP)と呼ばれるソフトウェアプロキシの機能追加・改善に取り組みました。
今回は、インターン中に行ったタスクのうち、他のチームとコミュニケーションを取りながら進めたものについてご紹介します。
LINEのサービスを支えるプライベートクラウド「Verda」
Verdaは、社内で開発・運用されているプライベートクラウド基盤です。
私たちのチームは、VerdaがManaged Kubernetesとして提供しているVerda Kubernetes Service(VKS)の開発と、Kubernetesを活用したVerda開発者の運用・開発体験の向上を行っています。
Verdaは、オープンなIaaS基盤であるOpenStackをベースに構築されています。Verdaには、OpenStackのコンポーネントをそのまま利用しているものだけでなく、一からフルスクラッチで実装したコンポーネントも存在します。例えば、VerdaのLBaaSは、社内でフルスクラッチ開発されたコンポーネントを使用しています。
Verdaについては、以下の記事に詳しく載っています。もしご興味があれば、ご参照ください。
- 【Team & Project】OpenStackとKubernetesを用いたVerda Platformを開発しているチームを紹介します
- Introduction of Private Cloud in LINE
- LINE Engineerを支える CaaS基盤の今とこれから
VerdaにおけるAPI開発
現状、Verdaが提供する各種API Specに対するアクセシビリティは、一貫性を欠いた状態です。具体的には、API Serviceごとにスキーマの正確性にばらつきがあったり、スキーマそのものへのアクセス手段が統一されていません。Verdaでは、現在約50種類のAPIサービスが動作しています。これらのうち、ほとんどのAPIに関するドキュメントが社内Wikiページに存在し、APIサービスとは独立した形で人力メンテナンスされています。Verdaプラットフォーム開発チームでは、この問題に対処すべく、「スキーマファースト」で開発を行っています。
「スキーマファースト」とは、サービスを開発する前の設計段階でAPI仕様を確定し、スキーマファイルに落とし込んだ上でコーディングを行う手法です。「スキーマファースト」には、APIドキュメント整備の労力削減や、複数サービス間の仕様すり合わせが簡便になるなど、様々なメリットが存在します。実際、VKSが提供するAPIについては、スキーマファイルから自動生成したAPIドキュメントを開発者向けに用意しています。スキーマファイルの代表的な規格としては、OpenAPI Specification(OAS)1)が挙げられます。社内でも、OASがスキーマファイルとして採用されています。
「スキーマファースト」の取り組みは、Verdaが提供する全てのサービスには展開できていません。Verdaプラットフォーム開発チームでは、他のチームやサービスにも「スキーマファースト」の取り組みを広げ、Verda全体のAPI Serviceの品質改善につなげようとしています。具体的には、OASをベースに、リクエストの検証やエンドポイントごとのメトリクス集計を行うソフトウェアプロキシを開発し、「スキーマファースト」の導入を支援しています。
抱えていた課題
「スキーマファースト」で開発されたAPI Serviceのスキーマは、実際に動作しているAPI Serviceの挙動と常に一致しているはずです。実際、我々が「スキーマファースト」で開発しているAPIにおいて、APIスキーマと実際の挙動は一致しています。一見すると、「スキーマファースト」の取り組みを広げることによって、API Serviceの品質は自然と改善されるように思えます。
しかし、Verdaでは様々なOSSを採用しており、中にはOASのスキーマファイルが存在しないものがあります。代表的な例としては、VerdaのIaaS基盤として採用しているOpenStackが挙げられます。OpenStack APIは、利用者がVerda上のリソースを操作できるように、リソースの利用者に対して開放されています。OpenStack APIにはOASのスキーマファイルが存在しないため、社内で別途スキーマファイルを作成・管理することで対応をしています。
手動によるスキーマファイルの保守には限界があり、実際のAPIの挙動とスキーマファイルの間に齟齬が生じる場合があります。前述の通り、リクエストの検証はスキーマファイルを基準に行われます。そのため、リクエストの形式がサービス側で処理可能だったとしても、スキーマの誤りによって違反と判定されます。
以上の背景から、スキーマファイルの不備や、実際の挙動との解離を観測することのできる仕組みが必要とされていました。
Verda Common Proxy(VCP)
本課題を解決するにあたり、我々が活用しているソフトウェアプロキシが、どのように動作しているかを説明します。
Verda Common Proxy(VCP)は、Verdaを構成する様々なコンポーネントが共通して使用する機能(認証や監査ログなど)が実装されたソフトウェアプロキシであり、Verdaプラットフォーム開発チームが開発を行っています。
以下の図は、VCPを利用したサービスに対してリクエストを送信した様子を表しています。VerdaのControl-Plane(C-Plane)を構成するコンポーネント、およびVerdaが提供するサービスの多くは、Kubernetesクラスタ上にデプロイされています。VCPは、これらのコンポーネントのSidecar Containerとしてデプロイされることを想定し、開発されています。VCPによって、サービスの開発者は認証や監査ログ等の共通機能について考慮する必要がなくなり、サービスの開発に注力することができます。また、VCPが共通機能を提供することによって、各サービスで共通機能に関して実装レベルや仕様のばらつきが出ることを防ぐことができます。
各APIサービスにおいて、リクエストのスキーマ検証作業も共通の機能です。VCPには、指定されたスキーマファイルをもとに、リクエストを検証する機能が実装されています。スキーマに違反したリクエストは、VCPによって処理されるため、サービス側には到達しません。この機能により、サービス側がスキーマ検証を行う必要を省略し、常にスキーマに準拠したリクエストのみを受け入れることができます。
これらの仕様を読み解く中で私が注目したのは、スキーマに違反したものだけでなく、スキーマ上で未定義のpathに対するリクエストも違反として処理されてしまう点です。この仕様だと、課題解決の目的である「スキーマの誤りや不足を検出する」という機能をうまく実装することができません。また、段階的にスキーマを実装していくような移行プランを採用することができないため、スキーマファーストな運用への移行障壁がとても高くなっています。
「緩い検査」の導入
前述の課題を解決するために、今回VCPへ新たに導入したのが「緩い検査」です。具体的には、スキーマに違反したリクエストをパススルーしつつ、違反したという事象と違反の種別をメトリクスという形で記録する機能です。ここでいう「緩い」とは、スキーマに違反したリクエストに対して400を返却する仕組みを「厳密」としたときの表現です。
「緩い検査」を導入することにより、APIスキーマと実際の挙動が乖離しうるサービスに対して、どのような種類のスキーマ違反がどの程度発生しているのか、メトリクスという形で知ることができます。
今までVCPには、「リクエスト数」「リクエストやレスポンスのサイズ」「処理中のリクエスト数」などのメトリクスが存在しました。今回、違反件数に関するメトリクスを追加するにあたり、2通りの手法を検討しました。
- 新たに「違反件数」を表現するメトリクスを用意する
- 既存のメトリクスに「ラベル」という形で情報を付加する
実装初期は、前者の方向で検討していました。しかし、VREチームとのディスカッションを経て、後者で実装することになりました。これは、「違反しているかどうか」という情報が、各リクエストに強く紐付いた情報だということに基づいています。VCPには、すでに「リクエスト数」に関するメトリクスが存在し、このメトリクスのラベルとして「違反種別」の情報を付加するのが妥当だと判断しました。
おわりに
今回実装した機能により、OAS非準拠なコンポーネントに対して段階的にスキーマの検証やAPIの可用性モニタリングを導入できるようになり、VCPを活かしたスキーマファーストな開発への移行障壁が大幅に低くなりました。今後、順次VCPの導入を進めていき、Verdaが提供するAPI Serviceの品質向上へと繋げていきます。
今回のタスクを進める上では、VerdaのSREチームにあたるVerda Reliability Engineering(VRE)チームの方を交えてディスカッションをしながら、必要な機能や実装の方向性を定めていきました。実のところ、このタスクは当初割り振られる予定のタスク群にはなかったものです。あらかじめメンターの方が用意していたスケジュールとは若干異なる進み方をしましたが、実際の現場ならではのライブ感があり、とても楽しかったです。
また、チーム内の公用語が英語だったこともあり、自分の伝えたいことを正しく伝えることを非常に意識したインターンシップでした。ドキュメントやIssueといったテキストベースの議論は比較的慣れていたのですが、Zoom上でメンターと話す時やDaily Meetingの時は聞きながら話さなければならず、非常に苦労しました。ただ、チームの方々の手厚いサポートにより、言語面・技術面の双方において大きな不自由はなく、スムーズに業務を行うことができました。
日本国内で、これほど英語を駆使して働ける職場は稀だと思います。プラットフォーム開発に興味のある方だけでなく、英語を駆使する職場に興味がある学生にとっては、非常に良い経験になると思います。
ぜひ、応募してみてください。
1) 以前はSwaggerと呼ばれていた仕様で、Version2とVersion3が存在します。https://swagger.io/specification/