こんにちは、SREをやっている@okazu_dmです。
経歴としては、サーバサイドエンジニアからセキュリティエンジニアを経て、エス・エム・エスではサービス横断で技術的な課題を解決しています。 基本的には組織に必要なことと自分ができることや、やりたいことが交わるポイントで仕事をしており、現在はSREとして働いています。
今回は、過去の記事 とは違い、既存SREチームとは別に、介護事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトにスコープを絞って新しく立ち上げたSREチームとしての活動を紹介します。
リリース前のプロダクトのSREなので、一般的なSREの定義とは乖離する内容もある点ご留意ください。
リニューアルプロジェクトの概要
昨年末に出したフロントエンドの技術選定に関する記事 での説明と内容的な差分はありませんが、SREの業務の説明の前にこちらでも改めて触れておきます。
インターネットサービスとしては比較的長く稼働しているカイポケですが、ソフトウェアとして見ると、10年以上の時間の中で発生した様々な需要に応じる形で機能を継ぎ足されてきた大きなモノリシックアプリケーションです。
現在進行しているリニューアルプロジェクトは、カイポケのサービスの安定性やプロダクトの優位性を高めるべく、アーキテクチャレベルで見直しをかけ、部分ごとに移行する形でリリースしていく開発プロジェクトです。詳しくは以下のサイトをご覧ください。
リニューアルプロジェクトのSREチームの担当範囲
開発途中という性質上、プロダクト全体の仕様やシステム構造のボラティリティも高く、SREの役割もプロダクトの状況に応じて変化しています。 その上でチームの大きな目標として「システムが安定して動いている状態」と「システムを早く世の中にリリースできる状態」を維持することを目指しています。
実務的には現在は以下のような役割を担っています。
- インフラの設計&構築
- 内部的にサービスを分割する設計となるため、インフラについても各開発チームと分割統治する形をとっています。SREチームは全てのサービスが乗る基盤となるインフラを担当しています。
- 開発プロセスの大まかな整備
- 同じAWSアカウント上で複数チームが同時並列で開発を進めるために、アカウント全体の利用ルールやコスト管理などはSREチームの担当としています。
- モニタリング基盤の整備
- モニタリングに利用する外部SaaSの選定やシステム全体のアーキテクチャにどのようにモニタリングを組み込むかについてはSREチーム主導で検討し、構築を進めています
今後の開発の中でプロダクトの全体像が明確になっていくにつれて役割が増えることが予想されますが、現状は以上が主要な業務です。
直近の技術的トピック
SREチームでは前述のように役割が流動的なため、日々の業務に伴い広くツールや外部サービスの技術検証や導入を行っているのですが、その中でもこの場に書きやすいものをピックアップしてご紹介します。
認証基盤の選定
リニューアルするに伴い認証部分についても検討が必要になりました。これについてはSREチームを含む一部のメンバーで最初にいくつかの候補を出し、最終的にAuth0を採用することに決めました。
大まかな方針として、「ユーザの認証情報を社内に持たない」点と「各開発チームが簡単に扱える(独自仕様が少なく直感的である)」点を重視して選定しました。
候補としたものと、調査した結果の短い所感をそれぞれ以下に書いていきます。
- Google Identity Platform: 特に不足はなさそうだが、Auth0のほうが便利そうだった。
- Amazon Cognito: 他のソリューションと比べて安上がりだが、仕様がやや独特で開発者全員がスムーズに理解できるかは不安があった。
- Azure AD B2C: 安くて安定していそうだが、Azure自体を触ったことがなく使いたい機能が限定的であるのに対して未知の部分が多いため今回は見送り。
汎用的なモニタリングのパイプラインの実現
こちらでは、具体的にはOpenTelemetry関連ツール導入の実現可能性について検証し、実際に導入して分散システムのモニタリングの構築を進めている現況の紹介をします。
OpenTelemetry
まず、OpenTelemetry(以下で一部otelと略していることもあります)について簡単に紹介します。 プロジェクトの公式サイト( https://opentelemetry.io/ )から引用したものを日本語訳して貼りますが、以下のように表現されています。
OpenTelemetryは、ツール、API、および SDK の集合です。テレメトリデータ(メトリクス、ログ、およびトレース) を計測、生成、収集、およびエクスポートし、ソフトウェアのパフォーマンスと動作の分析に役立てます。
これだけだと理解が難しいかと思うので、公式の図を踏まえつつもう少し具体的な紹介をします。
図の中心にあるOTel Collector(以下単にCollectorと称する)が重要な役割を果たすツールです。これは、アプリケーションやインフラ(図の左側のコンポーネント群)から能動的または受動的にテレメトリデータを吸い上げ、Collectorがサポートするいくつかの形でエクスポートします。エクスポート先の例としては以下のようなものが存在します。(https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter より)
- Jaeger
- Zipkin
- Prometheus
- Datadog
- AWS X-Ray
また、アプリケーション側が自動でリクエストや関数呼び出しなどの単位(上記の公式の文中にあるテレメトリデータの中で言うところのトレース)で処理の実行記録を残すために、アプリケーションに組み込む計測用ライブラリも開発されています。
これは使い方の一例ですが、例えばDatadogの従来の導入方法は、公式のライブラリをアプリケーションに組み込み、Datadog Agentを立ててDatadog Agent経由でDatadogにログやトレースを送る、という形でした。これのもう一つの選択肢として、ライブラリをDatadogのものからOpenTelemetry用のものに変更し、Dataodg Agentの代わりにCollectorを導入することで同様のことが実現できるようになりました。
このように、OpenTelemetryは従来のベンダが個々に作っていたモニタリングのパイプラインの一部を統一的な形で実現しています。
導入の背景
OpenTelemetryを導入すると何ができるのか、という点については前述したように、少なくとも現状の我々の利用範囲だと何か新しいことができるようなものではありません。
その上でOpenTelemetry導入に至った経緯について説明します。
まず、今回のプロダクトでは初期のリリースの規模などから見てもモニタリング基盤は外部のソリューションに任せた方が良いだろうという方針でDatadogを採用することにしました。
そして既に社内でOpenTelemetryを採用しているチームがあった点と、プロダクトが拡大した場合はDatadog以外のソリューションを検討することもあるだろうという将来的な可能性を見据えて、サービス間の乗り換えが比較的容易そうなOpenTelemetryを採用しました。
Datadog Agent vs OTel Collector
Datadog AgentはOTLP(OpenTelemetryProtocol)のメッセージを受けることが可能なので、OpenTelemetryを採用する場合でも以下の図のようにCollectorを使うか、Datadog Agentを使うかの選択肢が発生します。
それぞれ単純なアプリケーション1つの環境でsidecarとして動作させて、デプロイ時の落とし穴がないか、という点やコンピューティングリソースの消費量などをざっくり確認してみました。検証の結果、どちらも単体で使う分には大きな差はないように見受けられたため、中長期的にCollectorの柔軟性が活きることを期待して、Collectorを標準のツールとして採用しました。
また、計測用のライブラリについては未検証ですが、OpenTelemetryのものを使ったコンポーネントとDatadog製のものを使ったコンポーネントを同時に使った場合、分散トレーシングに問題が出るのではないかと考えています。
具体的には以下のように、DatadogとOpenTelemetryの間でトレースのIDのデータフォーマットが違う点が問題となることが予想されます。
なお、仕組みの話を補足するとトレースのID自体は計測用ライブラリ側で生成しており、OpenTelemetryのライブラリを利用した場合Datadog AgentやCollectorのDatadog ExporterがDatadogに送る前にフォーマットを変換しているようです。
例: Datadog Exporterでフォーマット変換していると思われる箇所
現状の懸念
ここまで、利便性や今後の可能性について様々な点から紹介してきましたが、一方で現状で本番投入するにあたっては以下のような懸念もあります。
- Stableでない部分も多く、各種データの吸い上げからエクスポートの部分までをすべて公式が実装していた状態よりは今後の不安がある(どちらか片方の破壊的変更が今後起こった場合など)
- 現在、sidecarとしてAWS FireLens(fluentbit)*1とCollectorを立てているが、関係する要素が増えると事故が起こる可能性もそれだけ増えるため可能であればもっと単純な形に置き換えたい(単純計算だとシステム内部に直列で繋がる要素が増えると事故率は上がる)
まとめ
この記事では、現在進行中のカイポケリニューアルプロジェクトのSREチームが担っている役割についての紹介をしました。
また、SREチーム内の直近の業務紹介の中で、OpenTelemetryの紹介とDatadog連携についての調査内容の一部分を要約して説明しました。
興味を持っていただけた方は、直近での転職意思の有無にかかわらず、ぜひカジュアル面談にお越しいただければと思います。
*1:ECSタスクのログをS3に転送するために使用しています https://aws.amazon.com/jp/blogs/news/under-the-hood-firelens-for-amazon-ecs-tasks/
