はじめに
2025年6月14日に開催されたCyberAgentの1dayインターン「Architecture Challenge」に参加しました。このイベントは、SREやプラットフォームエンジニアリングに関心のある学生を対象とし、実際の業務に近いマルチテナント環境でのプラットフォーム設計を体験できる貴重な機会です。
私自身、これまで法人向けSaaSの開発やインフラ構築、CI/CDの整備などに携わってきましたが、単に技術を磨くだけでなく「なぜこのシステムを作るのか」を理解しながら、開発者が最大限の力を発揮できる基盤を整備することに大きな関心があります。今回のチャレンジでは、そうした価値観を実際の設計タスクに反映し、実践的な気づきや学びを得ることができました。
Architecture Challengeとは
CyberAgentが主催する1日完結型の実践的インターンで、インフラ・SRE・クラウドアーキテクチャ設計に興味のある学生向けに提供されています。詳細は以下の公式ページをご参照ください：
CyberAgent Architecture Challenge 2025 公式ページ
具体的な課題に対する言及は避けますが、このインターンでは、急激なアクセス増加にも耐えられる柔軟な仕組みを備えつつ、複数のWebサービスを効率よく運用・拡張していくための“スケーラブルなプラットフォーム”を設計する力が求められました。
また、実装技術には制限がなく、自分で自由に技術スタックを選べる点も本イベントの魅力のひとつです。評価軸としては、可用性・耐障害性、パフォーマンス、コスト効率、メンテナンス性、高度なプラクティスの実践度などが設定されており、現場のエンジニアとしての視点が問われる課題設計になっていました。
設計への取り組みと構成の背景
私が設計したアーキテクチャを紹介します。限られた時間の中での設計となったため、現時点で不完全な点もありますが、課題要件を踏まえて構成全体を俯瞰しながら、できる限りの工夫を凝らして設計しました。下図は当日提出した構成図です。
（※本記事の後半では「どのように改善できたか」「次に活かしたい反省点」についても振り返っています)
ビジネス要件に合わせて工夫した点は、まず「突発的なアクセス集中」への対応として、CloudFrontをCDNとして採用し、静的コンテンツ配信を高速化するとともに、オリジンサーバーへの負荷を軽減しています。また、ALBとAuto Scalingを組み合わせて、EC2インスタンスが柔軟にスケールする構成をとることで、アクセスの急増にも対応可能としました。
可用性と信頼性の確保に関しては、RDSのマスター・スレーブ構成を採用し、フェイルオーバー対応を前提としたプライベートサブネット構成を構築しています。これにより、万が一の障害発生時でも最低限のダウンタイムでサービスを継続できる設計を意識しました。
コスト最適化の観点では、各EC2インスタンスを用途に応じて適切なリソースサイズに設定し、トラフィックに応じたスケーリングを行うことで、無駄なリソース消費を抑えつつ可用性を保てるよう工夫しました。また、共通機能（決済・通知・認証）についてはLambdaやSESなどマネージドサービスを活用することで、開発・運用のコストも軽減しています。
さらに、開発体験向上と運用効率を意識して、ECRやGitHub Actionsを用いたCI/CD、CloudWatchを中心とした監視・通知基盤（SNS→Chatbot連携）を整備しています。これにより、エンジニアが安心してデプロイ・運用できる土台を整えることができました。
フィードバックから得られた改善点と学び
今回のチャレンジでは限られた時間の中で設計を行いましたが、メンターの方々のフィードバックや模範的な回答例を通じて、自身のアーキテクチャにはまだ多くの改善余地があることを学びました。
特に印象的だったのは、開発者が複数のサイトを担当する現実的な運用を踏まえた設計という視点です。私の構成では各サイトごとに分離されたインフラ構成を想定していましたが、実際には1人のエンジニアが複数サイトを保守することが多く、サイトごとに大きく異なる構成を許すことは、管理負荷や保守性の低下に繋がるリスクがあると気づきました。
改善点として特に重視すべきだったのは以下の3点です：
-
KubernetesとNamespaceによるマルチテナント管理
各サイトを Namespace で分離しつつ、共通機能とのやり取りを Service Mesh（Istio）で制御する構成は、可観測性や制御性、スケーラビリティの面で非常に優れていると感じました。 -
GitOpsとTerraformモジュールの活用によるDX向上
プラットフォームチームがリソースを一括管理するのではなく、各サービスエンジニアが自律的に構築・デプロイできるよう、ArgoCDやTerraformのモジュール化とその共有を行うというアプローチは、理想的な開発体験（Developer Experience）に大きく貢献するものでした。 -
FinOps視点でのコスト可視化と最適化
サービス単位でのコスト可視化（OpenCostやBigQuery連携によるラベル集計）、クラスタリソースの効率的な利用（Affinity + Spot VM戦略）など、技術選定だけでなく「運用における継続的な最適化」の視点が不足していたと反省しました。
こうした知見は、現場の制約やスケールする組織構造を考慮した設計がいかに重要かを再認識させてくれるものでした。今後は、アーキテクチャ設計においても「チームの構成」「開発体制」「運用の継続性」まで含めた視座を持ちながら、より柔軟で運用可能性の高い基盤設計を目指していきたいと思います。
1dayインターンに参加してみて
今回のArchitecture Challengeを通じて、これまで知らなかった技術や概念に数多く触れることができ、新しい分野への好奇心が強く刺激されました。
特に印象に残っている学びは、以下のような点です。
-
技術選定は「なぜこの技術を選んだのか」を説明できることが重要であり、名前だけで選ぶのではなく、実装や構成レベルまで理解して選定する必要がある
例として、Lambda や ECS の採用についても、「使えるから使う」ではなく、クラスタ構成やマルチテナンシーの観点から設計上の意味合いを捉える必要があると感じました。 -
Kubernetesのスケーラビリティと柔軟性の強さを再認識
大規模な構成に対応するKubernetesは、EKSのように運用の難しさを伴うものの、Namespace単位でのテナント分離や段階的なオートスケーリングといった強力な機能を持っており、サービスの信頼性を支える基盤として非常に魅力的だと感じました。
-
最新の情報や設計動向はCloud Native Landscapeやカンファレンス等で日々更新されており、情報感度の高さが求められる
→ 見慣れてくると「このプロダクトはこういう位置付け」といった視野が広がり、自分の設計思想にも深みが出てきます。
-
Kubernetesを理解し、Manifestを記述・運用できるバックエンドエンジニアの強さ
単にAPIを実装できるだけでなく、それを本番環境にデプロイし、CI/CD・監視・スケーリングまで一気通貫で扱えるスキルは、今後ますます重要になると感じました。
-
SREの視点では、「アプリケーション層で対応するか」「インフラ層で捌くか」を状況に応じて調整する力が重要
コストやパフォーマンスの観点から、責任をどの層に持たせるのが適切かという判断力が問われる場面が多いと学びました。
この1dayインターンは、ただの短期的な体験にとどまらず、「これから何を学ぶべきか」「どこを深めるべきか」の羅針盤として、自分のキャリアに深く関わる学びを与えてくれました!
おわりに
CyberAgentのArchitecture Challengeは、単なる設計演習ではなく、「実務に近い課題に納得感を持って立ち向かう力」を試される貴重な機会でした。SREやプラットフォーム設計に興味がある学生にとって、これほどリアルな設計思考を養える場は他にあまりないと感じています。また、他のインターン参加者の方の発表も聞いてとても学びが多かったです。
本記事が、今後このイベントに参加する方の参考や、クラウドアーキテクチャに興味を持つ方の気づきになれば幸いです。