最後にはじめにこんにちは。コミューン株式会社のSREチームでアクティングマネージャーをしています。今日は当社のプロダクトであるcommmuneのアーキテクチャについてざっくり紹介していきたいと思います。今回公開に至った動機としては知見の共有が最も大きいです。運用負荷が比較的低いマルチテナントSaaSのアーキテクチャの具体的な一例として、どのようなアーキテクチャにしようか悩むエンジニアの参考情報になると嬉しいです。現在のアーキテクチャについて正直素晴らしいエレガントなアーキテクチャだとは思っていません。改善すべき箇所はまだまだ存在しています。改善に改善を重ねつつ必要なところでは負債を返して(あるいは返そうとして)おり現実的に戦っていけるアーキテクチャではあるなと自負しています。(あわよくば改善提案、今後ぶち当たりそうな問題など諸先輩方のフィードバックをいただけると非常に助かります。『こんなアーキテクチャぶっ壊して俺が最強のアーキテクチャを作るんだ!』っていう気合の入った方も是非当社の開発チームに応募いただきたいです!)では紹介していきます。何?アーキテクチャについて紹介する前にその前提となるサービスとその特性について簡単に紹介させてください。BtoBtoXのSaaSで、コミュニティサクセスを実現します。https://commmune.jp/)詳細はLPから見ていただけると良いです。基本的な機能はコミュニティ構築とその運用支援、自動化です。構築されたコミュニティは当社のインフラの上でマルチテナント的に動作します。ユーザはそのコミュニティの中で様々なアクションをすることができます。代表的なものとしては投稿の閲覧や投稿です。これらのアクションに応じてトラフィックが発生します。受け取るHTTPリクエスト・トラフィックについては以下のような特性があります。基本的には低負荷マーケティングキャンペーン等の利用でスパイクすることがあるこの特性を念頭においてアーキテクチャとその問題点について話していきたいと思います。以前のアーキテクチャは非常にシンプルな作りでした。簡易的な図がこちらです。Engineの内部でフロントとバックエンドのサービスを運用していました。SQLを利用していました。サービスの立ち上げ当初はこのアーキテクチャで問題なく運用できていたのですがサービスの成長・ユーザの増加にしたがって段々と問題が噴出し始めました。以下で背景を含めて紹介します。問題1:増減するトラフィックに対してコスト最適なマシンスペックを設定するのが運用上難しかったトラフィックは大幅に増減するのに対して、コンピューティングリソースはサービスを停止しないと変更できなかったために普段のトラフィックでは必要のないレベルの性能のマシンを常に動かす必要に迫られていました。シンプルに費用対効果が悪い作りになっていました。問題2:トラフィックのスパイクでサービスが過度に不安定になっていたサービスの成長、顧客数の増加とともに想定していない数のトラフィックが来るようになりました。その結果サーバーの処理性能を超えてしまうことでサービスが不安定になっていました。キャパシティプランニングが不足していたことも原因の一つでした。問題3:動作環境としてのVMの管理が煩雑になってしまっていたIaCツールを用いた設定が行われておらず手動で設定が行われていました。これにより各環境で各種ミドルウェアのバージョンを調整したりするのが苦痛な作業となって運用負荷が上がってしまっていました。実際に環境ごとに多くの差分が発生していました。差分の影響で問題が発生することはなかったのですがこれはおそらくただのラッキーだったと思っています。このような問題が積み重なった結果、抜本的な問題解決のためにアーキテクチャを見直すことになりました。打ち手としての新アーキテクチャ上で述べた問題を解決すべくアプリケーションの基盤を移行することになりました。新アーキテクチャ移行後の姿がこちらです。Runへと移行しました。Engineで動作しています。)これにより旧アーキテクチャの抱えていた問題点が大幅に改善されました。Runを利用することでDockerfileでの環境定義が行え、ランタイムへの変更の反映も容易になりましたサービス選定の内訳サービス基盤の選定のための制約条件としては以下のようなものがありました。GoogleCloudのサービスであることGoogleCloudにロックインしておりマルチクラウド化のコストを払える体制でなかったためオートスケールする基盤であることサービスの成長に従って継続的なトラフィックの増加が見込まれたため移行作業のコストが低いこと移行を決めたタイミングでは既にトラフィック起因のサービス障害が起こり始めており移行までの猶予がかなり短かったため技術的な知見を持っているメンバーがいるかどうか旧アーキテクチャにおいて発生していた問題が解消・緩和されること実際に選択肢にのぼっていたものとしては以下がありました。Cloudのサービスです。Engine上で動かすのが難しいことが判明しました。理由は以下のようなものでした。Engineのフレームワークにそぐわなかったこと(正確にはFlexible環境を使えば実現可能そうでしたがかなりリファクタリングをする必要がありそうでした。)そこで最終的に柔軟にランタイムの定義が可能でかつ制約条件を全て満たすCloudRunが採用されることになりました。成果なんやかんやあって新しいアーキテクチャでのリリースが終わりました。結果としてサービスの安定性も増し、運用が信じられないくらい楽になって運用負荷の低減とサービス品質の向上でチームとしては大満足な結果でした。スケールアウトのための深夜メンテナンスもいらなくなったことに加え、デプロイ時のローリングリリースの安心感も増しました。Runは大好きなサービスの一つです。移行は完了したもののサービスのフェーズは絶えず変化し続けており、呼応するようにアーキテクチャへの要求も流動しています。現在のアーキテクチャが完全な理想郷というわけでなく他にも様々な課題が現れてきています。かいつまんで紹介します。海外進出をうけたデータの配置場所の整理メールや通知処理のリアーキテクチャetc...インフラに関連する部分で思いつくままにあげてみました。多くの改善点があります。これからもチームとしてさまざまな課題にチャレンジできることを楽しみにしています。最後に簡単にアーキテクチャの紹介を行わせてもらいました。当社のSRE、エンジニアチームではさまざまな職種の方を絶賛採用しています。よいプロダクトを作りたい方、課題を解決することが好きな方と一緒に働けると嬉しいです。私個人のMeetyも貼っておきます。https://meety.net/matches/sAdpUSpSyKoD採用文脈以外でも仕事について気になること、質問、情報交換などあれば気軽にカジュアル面談の申し込みをしてください。最後まで読んでいただきありがとうございました。