クラウドネイティブ開発で得た3つの教訓

クラウドネイティブ開発で得た3つの教訓

――AWSで「伸び続けるシステム」をどう設計するか

オリエンタルヒルズ株式会社では、複数のクライアント案件および自社サービスにおいて、AWSを中核としたクラウドネイティブアーキテクチャを採用してきました。
単なるインフラ移行ではなく、事業成長に耐えうる設計と運用へ刷新すること。その実践の中で見えてきた「3つの教訓」を、具体的な構成例とともに共有したいと思います。

教訓1：スモールスタート × 正しいサービス選定

クラウド移行で最初に直面するのは、「どのサービスを選ぶべきか」という設計判断です。
私たちが重視しているのは、いきなり“理想の完成形”を狙わないことです。

典型的な構成例（中規模Webサービス）

• フロントエンド：Amazon CloudFront ＋ S3（静的ホスティング）
• バックエンド：AWS Fargate（ECS）上のコンテナ化アプリケーション（Node.js / NestJS など）
• データベース：Amazon Aurora Serverless v2（MySQL/PostgreSQL互換）
• 認証：Amazon Cognito
• 監視：Amazon CloudWatch, AWS X-Ray
• ネットワーク：AWS WAF + ALB + Private Subnet

この構成は、以下の点で「スモールスタート」と「将来の拡張」のバランスが取れています。

• 初期は単一クラスター＋数サービスで運用しつつ、負荷や機能要求に応じてマイクロサービス化へスムーズに分割可能
• Aurora Serverlessにより、利用量に応じた自動スケールで無駄なDBリソースを抑制
• CloudFront＋WAFでセキュリティとパフォーマンスを最初から標準装備

ポイントは、「とりあえず全部マイクロサービス」「とりあえずKubernetes」ではなく、
事業フェーズに見合った“ちょうどいいマネージドサービス”を選び、小さく始めて大きく育てることです。

教訓2：CI/CDとIaCは「開発スピード」ではなく「経営リスク」を下げる

AWSを活かしきるうえで、IaC（Infrastructure as Code）とCI/CDは必須です。

実践しているパイプライン例

• コード管理：GitHub
• CI/CD：GitHub Actions → Amazon ECR → Amazon ECS(Fargate) / Lambda へ自動デプロイ
• IaC：Terraform または AWS CDK によるVPC、ALB、ECSサービス、RDS/Aurora等の一括管理
• 品質管理：自動テスト（Unit/E2E）＋ Lint ＋ 静的解析

これにより：

• 手作業の設定ミスを排除し、障害発生時の原因追跡が容易
• 環境差異（本番・検証・開発）の再現性が高く、リリースサイクル短縮
• 属人化していた「この人にしか分からない設定」がコード化され、事業継続性が向上

経営者として見ると、これは「開発効率化のための贅沢」ではありません。
設定ミスや人依存によるシステムダウンという“経営リスク”を減らすための投資です。
AWSはマネージドサービスが豊富だからこそ、それらをきちんとIaCで定義し、CI/CDで安全に回す文化が不可欠だと痛感しています。

教訓3：サービス比較の軸は「技術好み」ではなく「運用ストーリー」

AWSには選択肢が多く、議論が「どれが好きか」になりがちです。
しかし、私たちが重視しているのは**「運用ストーリーが描けるか」**です。

例1：ECS Fargate vs EKS(Kubernetes)

• ECS Fargate
• • メリット：インフラ管理を最小化、学習コストが比較的低い
  • 適合：小〜中規模、運用チームが限られる環境、早く安定させたいプロジェクト
• EKS
• • メリット：Kubernetes標準エコシステムをフル活用可能、大規模・マルチクラウド戦略に相性
  • 適合：専任SREチームがいる、マイクロサービスが多数、将来的なポータビリティを重視

私自身の判断基準：

「このプロジェクトの規模・人員・3年後の姿を考えたとき、運用し続けられるのはどちらか？」

という問いに対して、冷静に答えられる方を選びます。

例2：Aurora vs DynamoDB

• Aurora：既存RDB資産との親和性、複雑なJOINやトランザクションが必要な業務システム向け
• DynamoDB：超高スループット、シンプルなアクセスパターン、大規模トラフィック向け

「NoSQLの方が新しいから」ではなく、
データアクセスパターンとビジネス要件から逆算して選ぶこと。
これもまた、クラウドネイティブ時代の基本姿勢だと考えています。

オリエンタルヒルズの取り組みと実績

オリエンタルヒルズ株式会社では、これらの思想をもとに、AWSを活用した数多くの開発実績を積み重ねてきました。
特に以下のようなプロジェクトでは、技術的挑戦と事業成長の両立を実現しています。

• 大手小売業向け EC基盤再構築プロジェクト
  旧オンプレ環境からAWSへ全面移行。FargateとAurora Serverlessによるオートスケール構成を実現し、
  トラフィック急増期にも安定稼働。運用コストを約35％削減。
• AI活用型カスタマーサポートシステム開発
  Amazon SageMakerとLambdaを組み合わせ、自然言語処理によるFAQ自動応答を実装。
  顧客満足度と一次解決率の向上を同時に達成。
• 自社SaaSプラットフォーム構築
  AWS Amplify × API Gateway × DynamoDB により、フルサーバーレス構成を採用。
  少人数チームでも高可用・高保守性の開発体制を維持。

これらの取り組みはすべて、「技術が事業を支える構造をどう設計するか」という視点から始まりました。
AWSを使う目的は“最新技術の導入”ではなく、“変化に強い事業基盤を築く”ことにあります。

終わりに：AWSは「箱」ではなく「設計と文化の鏡」

AWSを導入したからといって、自動的にモダンな開発になるわけではありません。
どのサービスを選び、どこまで自動化し、どう学び続けるチーム文化をつくるか。

クラウドネイティブ開発で得た3つの教訓をまとめると：

1. スモールスタートできる構成を選び、成長に合わせて拡張できる余白を設計すること
2. IaCとCI/CDで“人依存のリスク”を減らし、品質と再現性を経営レベルの資産にすること
3. サービス選定は「好み」ではなく「運用ストーリー」「事業戦略」から逆算すること

オリエンタルヒルズ株式会社は、これからも「技術的に正しいだけでなく、事業として持続可能なアーキテクチャ」を提案し続けていきます。