マルチプロダクト構成を支える KANNA のインフラアーキテクチャ

はじめに

こんにちは、KANNA の SRE チームの okenak です。

今回は、KANNA のプロダクトを支えるインフラアーキテクチャをご紹介します。
複数のサービスで成り立つ仕組みの中で、どうやって「止まらない」かつ「スケールできる」環境をつくり、さらに開発効率とコストのバランスを取っているのか。
その工夫や取り組みをまとめました。

アーキテクチャの全体像

マルチサービスアーキテクチャ

KANNA はマイクロサービスではなく、モノリポをベースにした複数サービス構成です。
サービスごとに独立して開発・デプロイでき、それぞれに合った技術スタックを採用しています。

📦 KANNA Product Suite
├── 🎨 フロントエンド (TypeScript + Next.js)
├── 🚀 コア API (Ruby on Rails)
├── ⚙️ 非同期ジョブ (Sidekiq Enterprise)
├── 🔌 OpenAPI サービス (TypeScript + Nest.js)
├── 📊 レポートサービス (Kotlin + Spring Boot)
├── ✅ 承認フローサービス (Kotlin + Spring Boot)
├── 💳 決済サービス (Kotlin + Spring Boot)
└── 🛠️ 管理ツール (TypeScript + Next.js)

---

クラウドインフラ戦略

KANNA のインフラは AWS を中核に据えつつ、GCP の強みを補完的に活用するハイブリッド構成を採用しています。
クラウドの特性を活かして、柔軟に組み合わせているのがポイントです。

---

AWS: プロダクトの中核を支える基盤

AWS は創業初期からの基盤で、今後もメインの実行環境として活用していきます。
アプリケーション、ネットワーク、データストアなど、主要なコンポーネントを集約しています。

コンテナオーケストレーション: ECS on Fargate

• マネージドサービス活用: Fargate で EC2 管理を不要化し、運用負荷を削減
• コスト最適化: ARM アーキテクチャとスポットインスタンスを活用
• 柔軟スケーリング: 自動スケーリングや適切なサイジングで負荷変動に対応

Blue/Green デプロイ

• CodeDeploy と連携し、ALB ターゲットグループを一括で切り替えてゼロダウンタイムを実現
• ヘルスチェックや監視アラートで異常を検知した場合は即ロールバック可能

ネットワーク最適化

• セキュリティ強化: プライベートサブネットで外部から直接アクセス不可
• コスト削減: VPC Endpoint で AWS サービス間通信を効率化
• 通信最適化: エッジロケーションで国内外からのアクセス遅延を低減

データストア戦略

Aurora は Multi-AZ 構成で、リーダー・ライターを分割するとともに、分析用のリードレプリカを追加して負荷を分散しています。これにより、可用性とパフォーマンスを両立した安定した運用を実現しています。

基盤の中心には Aurora MySQL を使い堅実に運用する一方、
新規の Kotlin + Spring Boot サービス群では PostgreSQL を採用。
既存の慣れにとらわれず、要件に応じた選択で将来の拡張に備えています。

---

Google Cloud: モバイルとデータ活用を支える補完基盤

AWS だけでは最適化しにくい領域を GCP で補完しています。
モバイルアプリの体験向上やデータ分析の高速化といったユースケースで、プロダクト全体の価値を高めています。

Firebase

• Authentication: ユーザーログインを簡素化し、自前で認証基盤を持たずに安全に運用
• Firestore: チャットや通知などリアルタイム同期
• Cloud Messaging: 高到達率かつ大規模配信に強いプッシュ通知基盤として活用

BigQuery

• アプリケーションログや監査ログ、利用状況データを格納し、分析・可視化を高速に実行
• サーバーレスでスケーラブルな設計により、初期負荷を気にせず利用でき、コスト効率にも優れる
• Redash などの BI ツールと連携し、意思決定に活用

---

モニタリングと可観測性

Datadog を中心に、メトリクス・ログ・トレースを一元管理。
異常検知から原因究明までをスムーズに行える体制を構築しています。

APM / Tracing でパフォーマンスのボトルネックを早期に把握し、
SLO 管理やアラートによってユーザーへの影響を最小化しています。

https://zenn.dev/aldagram_tech/articles/73c68a716c60d7

---

CI/CD パイプライン

GitHub Actions でビルド・テスト・デプロイを自動化。
外部の CI 基盤や管理サーバーを追加することなく、GitHub 上で完結できるシンプルな構成です。

パイプラインはソースコードと同じリポジトリで管理。
変更とデプロイ履歴を一元的に追跡でき、SRE 以外のメンバーも改善に参加しやすくなっています。
その結果、チーム全体で安全かつ俊敏にリリースを回せる環境を実現しました。

---

セキュリティ対策

セキュリティはサービス基盤を支える前提条件として、多層的な仕組みを組み合わせています。
境界防御から認証、運用アクセスまでをカバーし、リスク低減と運用効率の両立を図っています。

• アプリケーション層防御: WAF による SQLi / XSS の遮断
• 監視・検知: GuardDuty による脅威検知と監査
• 認証基盤: Cognito による社内環境の認証・認可
• 運用アクセス制御: SSM Session Manager による安全なオペレーション
• アカウント管理: AWS Organizations による分離管理、IAM Identity Center によるキー不要の運用

https://zenn.dev/aldagram_tech/articles/fefd52c93dd5a9

---

コスト最適化の取り組み

成長フェーズに応じてリソース利用を継続的に見直し、コスト効率の最大化を図っています。
基盤の安定性を維持しながらも、柔軟な最適化を繰り返すことで、持続可能な運用を実現しています。

• Fargate Spot & ARM の採用によって、コンテナ実行コストを大幅に削減
• VPC Endpoint の利用により、インターネット経由を避けて通信コストを抑制
• AutoScaling のチューニングで、負荷変動に応じたリソース効率化を実現
• Reserved Instance / Savings Plan を活用し、継続的に発生するコストを計画的に削減
• 検証環境の集約（10 環境以上を統合）により、不要な重複リソースを解消し、運用コストを軽減

https://zenn.dev/aldagram_tech/articles/cc18ca783aec11

---

IaC（Infrastructure as Code）

インフラはすべてコードで定義し、再現性と変更管理の精度を高めています。
Terraform / Terragrunt を採用し、state を Terraform Cloud で管理することで、誰でも同じ環境を安全に再現できるようにしています。

以前は CloudFormation を併用しており、一部のリソースはコード管理外となっていましたが、現在は全ての構成を Terraform に統一しました。これにより、管理の一貫性が高まり、運用負荷を軽減するとともに、変更履歴の追跡やレビューも容易になっています。

https://zenn.dev/aldagram_tech/articles/8e3bca57c98e83

---

今後のやりたいことや課題

現時点で緊急度は高くないものの、中長期的には以下の取り組みを進めたいと考えています。

技術課題

• ALB 間通信の内部化
  外部経由を排除し、通信を内部ネットワークに閉じることでセキュリティをさらに強化

• Terraform Cloud 依存からの脱却
  コスト面の高さや API Rate Limit の厳しさを解消し、柔軟性のある運用へ

戦略的チャレンジ

• データレイクおよび統合分析基盤の整備
  現在は Redash で最低限の分析をしていますが、データ範囲は限定的。
  今後はデータソースを広げ、BI や機械学習にも対応できる環境を検討。

• グローバルリージョン展開の検討
  海外需要や多地域冗長構成を視野に、最適な運用体制を模索

まとめ

SRE チーム発足以来、段階的にインフラ整備を進め、ようやく安定した基盤に育てることができました。ただし、インフラに完成はありません。プロダクトの要件や組織の成長に応じて、常に変わり続ける必要があります。

SRE チームでは、状況の変化に合わせて最適解を探りながら、一歩ずつ改善を積み重ねています。
完璧な形は存在しませんが、進化を続けることで柔軟かつ強固な基盤を維持できると考えています。

KANNA のインフラは、会社の成長とともに進化し続ける “生き物” のような存在です。
これからも変化を恐れず、より良い構成を目指して挑戦を続けていきたいと思います。