はじめに
こんにちは！クラウドサインでSREをしている @r_ueda_sanzai です。
昨夜、ファインディ株式会社様主催のオンラインイベント「インフラアーキテクチャ選択のジレンマ」に登壇しました。 当日は500名を超える皆様に申し込みいただき、大盛況のうちに幕を閉じました。
さて、今回のイベント。 「EKSとECS、どちらを選ぶべきか？」 「うちはマイクロサービスじゃないけど、本当にこのままで大丈夫だろうか？」 きっと、そんな思いを抱えながら参加された方もいたのではないでしょうか
本記事では、当日の発表内容をさらに深掘りしつつ、時間の都合でお話しきれなかった「私たちのリアルな判断軸」や、 他社様の発表から得た気づきなどを共有したいと思います。少しでも共感したり、皆さんのチームの状況と重ね合わせたりしながら、読んでいただけると嬉しいです。
当日の登壇資料
登壇資料はSpeakerDeckに公開しています。ご参照ください。
ECSでどこまでいけるのか?
登壇でも述べた通り私たちクラウドサインはマイクロサービスではありません。 サービスの特性も大いにありますが、これは裏を返せば「この規模のサービスまでは、ECSを使いこなすことで十分に対応可能である」という一つの証明だと考えています。
その際に重要視することがはゴールデンパスを提供することです。
ゴールデンパスとは開発者が共通のタスクを最も効率的かつ品質高く実行するための推奨された標準化されたワークフローや手法のことを指します。
クラウドサインにおいてはTerraformでECSサービス定義をモジュール化し、開発者が同じ品質でサービスを追加できる仕組みを整備しています。
# service-modules/ecs-service/main.tf resource "aws_ecs_service" "this" { name = var.service_name cluster = var.cluster_id task_definition = var.task_definition_arn desired_count = var.desired_count # ログ設定、VPC設定、ALB設定などを共通化 } # projects/foo-service/main.tf # 各サービスではモジュールを呼び出すだけ module "foo_service" { source = "../../service-modules/ecs-service" service_name = "foo-service" desired_count = 2 # ... サービス固有の変数を渡す ... }
（図：上記コードはあくまでイメージです）
こうすることでインフラ,SREチームに負荷が集中することを防ぎ 開発者がよりインフラをより早く開発に専念でき、より早くサービスをリリースすることができます。
なぜマイクロサービス化しなかったのか？当時の判断軸
今でこそ複数のチームで機能開発を行っていますが、サービス初期は、開発者全員で一つの大きなロードマップを追いかけていました。
「機能単位でチームを分ければ、それをきっかけにマイクロサービス化できるじゃないか」
そう考えるのが自然かもしれません。しかし、私たちはそうしませんでした。 プロダクトの方向性がまだ固まりきっていない黎明期にアーキテクチャを分割しすぎると、どうなるでしょうか。
例えば、「顧客管理」と「請求管理」のサービスを早々に分割していたら。
「請求履歴の一覧に、顧客の担当者名も表示したい」というだけの小さな改修のために、サービス間のAPI仕様の調整、複数リポジトリの修正、デプロイ順の考慮といった、見えないコミュニケーションコストが発生し、開発効率が大きく落ちていたかもしれません。
このように、システム全体の把握が逆に難しくなり、プロダクトの向かうべき先がズレてしまう。 私たちはそんな懸念を抱いていたのです。
アーキテクチャ分割に絶対の正解はありません。
ただ、サービスの性質や組織の成熟度を見極めた上で、私たちは「分割しない」ことが当時の最適解だと判断しました。
そして、その選択が今の成長スピードにつながっていると、自信を持って言えます。
私たちの現在地
今回私たちの現実に対応した現在のアーキテクチャを共有させていただきました。では、理想のアーキテクチャは不要なのか？ そんなことはありません。しかし、ソフトウェア開発は、教科書通りには進まないものです。
- これに対応してほしいといった次々と来る機能開発の要望
- ありがたい悲鳴でもある、プロダクトの成長に伴うアクセス数の増加と、それに伴うパフォーマンス維持の戦い
- あちらはこんな機能をリリースしたという、常に意識せざるを得ない競合プロダクトの状況
こうした様々な「現実」に、私たちは日々対応しなければなりません。
最初に定義した「理想」のアーキテクチャに向かって、ブレずに開発を進められるのは、本当に凄いことです。
しかし、私たちのように、目の前の課題を一つひとつ解決していくことで、結果として今のアーキテクチャにたどり着く、という道のりもあります。
大切なのは、自分たちのプロダクトと組織が今どのフェーズにあり、どちらのアプローチがより価値を生むのかを、常に見極め続けることなのかもしれません。
他社様の発表を聞いて・・・
マルチプロダクト×マルチテナントを支えるモジュラモノリスを中心としたアソビューのアーキテクチャ by アソビュー株式会社 兼平大資@disc99_
「逆コンウェイの法則」のように理想の組織からシステムを設計するという考え方に、純粋に驚かされました。
EKSシングルクラスターでのマルチテナント戦略や機能ごとのDB分離、gRPCとRESTの併用など、具体的な技術選定の背景まで詳細に解説いただき、大変勉強になりました。
自分たちのアーキテクチャを再考する上で、非常に多くの示唆をいただきました。
事業特性から逆算するインフラ設計：UPSIDERのマイクロサービス基盤構築の舞台裏 by 株式会社UPSIDER 金正朋也@thiefxx_
金融系サービスならではのトピックとして、PCI DSS準拠のアーキテクチャ設計の話も大変興味深かったです。
私自身、この要件について不勉強だったのですが、厳しい規制と技術的制約を両立させる難しさと、それを乗り越える工夫に、エンジニアとして強く惹かれるものがありました。
家族の思い出を形にする 〜 １秒動画の生成を支えるインフラアーキテクチャ by 株式会社MIXI 生島 光@ojima_h
「みてね」の、動画がアップロードされてからユーザーに届くまでのパイプライン解説は、非常に参考になりました。
また質問でも触れられていた膨大なS3データ量と、それに伴いBigQueryへのデータ転送に5時間も要するというお話は、こういったサービスならではのリアルな課題だと痛感させられました。
さらに自社のデータ基盤を考える上で大きなヒントになりました。
ライブ配信サービスのインフラのジレンマ -マルチクラウドに至ったワケ- by 株式会社ミラティブ Yusuke Hata@octu0
GCEはGoogle Cloud Platform版のEC2くらいのイメージでしたが、ライブマイグレーション機能が優秀だと知りました。
オンプレミスと組み合わせたマルチクラウド構成で、精緻なキャパシティプランニングを実践されている点はとても印象的でした。
インフラを深く使いこなす実例として、とても参考になりました。
まとめ
登壇では話せなかった深掘りや他社様の感想を共有させていただきました。
事業フェーズや組織の現実に合わせて、常に悩み、模索し続けることこそがリアルなアーキテクチャでというメッセージが誰かの心に届いていると幸いです。
最後になりますがこの登壇は、多くの方々のサポートのおかげで実現しました。
発表に向けて伴走してくださった技術広報の方、素晴らしいスライドをデザインしてくださった方、内容を的確にレビューしてくださったテックリードの方々。
そして、当日ご視聴いただいた皆様、このような貴重な機会をくださったファインディ株式会社様に、深く感謝申し上げます。
また、当日ご視聴いただいた皆様、このような素晴らしい機会をご提供くださったファインディ株式会社様にも、心より御礼申し上げます。本当にありがとうございました。
