MoTのSREグループが社内に提供している標準技術スタックを紹介

こんちには、SREグループの水戸です。今回はMoTのSREグループが社内に提供している標準技術スタックを紹介したいと思います。

なぜ標準技術スタックを定義するのか

Mobility Technologies (MoT)ではマイクロサービスアーキテクチャを採用しているため、大量のサービスが既に稼働しており、また日々新しいサービスも立ち上がっています。サービスを安定運用するにはロギングや監視、プロセスの起動方法、秘匿値の管理、セキュリティなど様々な非機能要件を適切に実装、設定する必要がありますが、マイクロサービスの開発チームがそれぞれ自由に様々な技術を採用してしまうとこういった安定運用に必要な機能が十分に実装されずシステム全体の品質低下につながるリスクがあります。 そのためSREグループでは検証や実際の運用を通して安定して運用できることが確認できた技術を標準技術として定義し、新規開発においては基本的にこの中から技術を選定する運用をしています。 この記事では実際に標準技術して選定している技術とその理由を紹介します。

標準技術スタック

MoTで動くサービスの大半はAPIサーバ、バッチサーバ、非同期ジョブサーバ、Webフロントエンド配信サーバのいずれかに分類されます。これらのワークロードをサポートすることを想定して技術選定をしています。(なお現時点ではAndroid、iOS、Webフロントエンドなどのクライアントサイドは標準化対象に含めていません)

アプリケーション実装

• 言語 Go, Python
• 外部向けAPI GraphQL, REST
• 内部向けAPI gRPC

ワークロードの種類に関わらずバックエンドアプリケーションの実装言語はGo、機械学習関連ではPythonを標準言語として採用しています。また、モバイルアプリやブラウザ等外部向けのAPIはGraphQLかRESTで実装、サーバ間通信用の内部向けAPIはgRPCを使用しています。(後述するKenos基盤上にIstioが稼働しており、Envoyによるクライアントサイドロードバランシングをしています) またアプリケーションの実装内容もある程度揃えるために、APIサーバを作るためのリポジトリテンプレートが用意されており、これを元に作ることで、Clean Architectureベースの基本設計、ロギング、CI/CD設定、データベースマイグレーションの仕組みなどが予め整った状態で開発を開始することができるようになっています。

コンテナ実行環境

EKS

バックエンドアプリケーションは必ずコンテナ化して実行します。実行環境としてはKubernetesベースの社内共通基盤KenosをEKS上で提供しており、オートスケールや監視、ロギング、CI/CDなどの仕組みをサービスによらず汎用的な形で実現しています。バッチサーバの場合も同じ基盤上でKubernetesのCronJobを使用して定期実行をしています。

データストア

Aurora MySQL、Aurora PostgreSQL

RDBはAurora MySQLをデフォルトの選択としつつ、PostgreSQLも選択可能としてます。小規模なマイクロサービスが多いためライターとリーダーの2台構成で構築していることが多いです。ごく一部短時間しか稼働しないバッチシステム等でAurora Serverless V1も使用しています。先日Serverless V2がGAしたため今後標準スタックに含めたいと考えています。

S3

ユーザからアップロードされたデータやサービスが生成したデータの保存などはS3を使用しています。多くの場合SSE-S3で暗号化し、アクセスログを有効化しています。必要に応じてSSE-KMSによる暗号化も使用します。

Elasticache Redis

アプリケーションのキャッシュデータの保存にはElasticache Redisを使用しています。基本的にクラスターモードを有効化しています。

DynamoDB

特殊な使い方かもしれませんが、MoTではDynamoDBを小規模ながら永続化したいデータを扱う際に非常に低コストなデータベースとして使うケースが多いです。ElasticacheやRDSのようにインスタンスベースで課金されるサービスの場合安くても月額数千円程度かかることになりますが、サーバーレスなDynamoDBだと月額数百円程度で済むこともあります。

BigQuery

DWHとしてGCPのBigQueryを使用しています。またRDBのデータをBigQueryに同期する方法としてDebezium Serverを使用しています。CDC方式で同期することで変更履歴も含めてDWHに保存し分析に使うことができるようになっています。

キュー

SQS

非同期ジョブサーバのジョブキューとしてSQSを使用しています。具体的なジョブとしてはメール送信やPDFファイルの生成などの時間のかかる処理を非同期実行しています。

Webフロントエンド配信

CloudFront + S3

フロントエンドは多くの場合SPA方式で開発しています。ビルドしたJSやCSSをS3にアップロードしてCloudFront経由で配信しています。

Amplify Hosting

一部サービスでNext.jsによるServer Side Renderingを実装しており、サーバレス構成でSSRに対応しているAmplify Hostingを使用しています。

モニタリング

New Relic

メトリクス収集、ダッシュボード作成、アラーティングはNew Relicで行っています。標準スタックの技術については取得するメトリクスやダッシュボード、アラートが全て予め定義されており、サービスインの時点ですぐに使えるようになっています。

監視の標準化については以前New Relic User Group Vol.0でご紹介しました。

BigQuery、S3

Kenosクラスタ上で動くすべてのアプリケーションのログはfluent-bitでコンテナ標準出力を回収し、fluentdに集約した上でBigQueryとS3に送信しています。BigQueryはコスト削減のため直近数ヶ月のデータのみを保持し自由にSQLでログ検索ができるようになっています。社内でホストしているRedashに専用のビューを用意してそちらからはSQLを書かずに検索できるようにもしています。

またそれより古いデータについてはすべてS3にバックアップとして保持し、必要な場合はAthenaで検索可能になっています。

CI/CD

GitHub Actions

CI/CDはGitHub Actionsを使用しています。ビルドとデプロイの全体の流れはリポジトリテンプレートに予め定義されており、開発者はブランチにマージするだけで自動的にテストとデプロイが可能な仕組みになっています。

CIについては以前はTravis CIを標準として使用してきましたが最近GitHub Actionsへの移行を進めています。機能性や管理のしやすさ、トレンドなどを考慮して移行を決め、SREグループが主導してTravis CIを使用している全サービスのビルド設定の移行作業を進めています。

まとめ

今回挙げた技術スタックはAPIサーバなどMoTで発生する典型的なワークロードを想定したものとなっています。ただ時にはその枠に収まらないワークロードもあります。そういった場合SREグループでは開発者と議論しながらより最適な技術を探し、それを新たな標準技術として採用することで徐々に対応範囲を拡張しています。またCI/CDのケースのように標準技術を使う中で課題が生まれたりより良い技術が生まれたらそちらに乗り換えて全体をアップデートしていくということもします。 標準を定義することは非常に重要だと考えていますが、それと同じくらい今現在の標準に固執せずその標準を変化させていくことも重要だと考えています。SREグループでは日々生まれる新しい技術にアンテナを張りつつ社内で求められる技術も想像しながら、より高品質なサービスの実現に向けて活動しています。

We're Hiring!

興味のある方は 採用ページ も見ていただけると嬉しいです。

Twitter @mot_techtalk のフォローもよろしくお願いします！