AWS ECSとAPI Gatewayを活用したPython/Java連携システムの構築術
目次
導入
既存のJavaサービスを維持しつつ、新規機能をPythonで開発したい──
そんなニーズは現場でよくあります。しかし、言語が異なるサービス同士を安全かつスケーラブルに連携させるには、アーキテクチャ設計が重要です。
本記事では、AWS ECSとAPI Gatewayを組み合わせて、PythonとJavaのサービスを連携させる構成を紹介します。
実際に構築した際のつまづきや工夫も交えて、すぐに実務で使える形でまとめました。
アーキテクチャ概要
データフロー（リクエストの流れ）
①クライアント ➡ API Gateway
・クライアント（Web/モバイル/社内システム）がAPI Gatewayにリクエストを送信
・認証（IAM / Cognito / Lambda Authorizer）をここで実施
・ルーティングルールに基づき、Python or Javaサービスへ振り分け
ポイント
API Gatewayを入口にすることで、
認証・スロットリング・ログ収集・APIバージョニングを一元管理可能！
②API Gateway ➡ ECS（Pythonサービス）
・Pythonサービスは軽量な処理や新規機能を担当
・API Gateway → VPC Link → ALB → ECS(Python) の流れ
・Python側で必要に応じてJavaサービスへ連携リクエストを送る
③Pythonサービス ➡ ECS（Javaサービス）
・PythonからJavaへは内部APIとしてREST通信
・VPC内通信のため、外部公開されない安全な経路
・Java側は既存の業務ロジックや重い処理を担当
④Javaサービス ➡ Pythonサービス（必要に応じて）
・双方向通信も可能だが、依存関係が複雑化しないよう、
「どちらがオーケストレーションを担うか」 を明確にするのが重要
⑤Pythonサービス ➡ API Gateway ➡ クライアント
・最終的なレスポンスはPython側で統合
・API GatewayがレスポンスログをCloudWatchに記録
・必要に応じてX-Rayでトレーシング
コンポーネントごとの役割
API Gateway
・認証（IAM / Cognito）
・ルーティング
・スロットリング
・ログ収集
・APIバージョニング
・VPC Linkで内部サービスへ接続
外部公開するサービスがAPI Gatewayだけで済むため、
セキュリティと管理性が向上するメリットあり。
ECS（Pythonサービス）
・新規機能や軽量処理を担当
・ALB経由でHTTPベースの通信
・スケールアウトしやすい
・デプロイが高速（コンテナサイズが小さい）
ECS（Javaサービス）
・既存ロジックや重い処理を担当
・NLB経由で高速通信
・JVMの起動時間やメモリを考慮したスケール設計
・レガシー資産を活かしつつモダン化できる
VPC / Security Group
・Python ⇄ Java の通信はVPC内で閉域化
・Security Groupで通信方向を厳密に制御
・外部からJavaサービスに直接アクセスできない構成
この構成を採用した理由
・API Gatewayで認証・ルーティングを一元化
・ECSでPython/Javaを独立デプロイ
・言語間連携をREST APIで標準化
・スケール戦略をサービスごとに分離できる
設計のポイント
この構成で重要になるのは、API Gateway・Pythonサービス・Javaサービスの役割分担を明確にすることです。API Gatewayは外部公開される唯一の入口として、認証・ルーティング・スロットリングを担当します。これにより、クライアントから直接ECSへアクセスさせず、セキュリティと管理性を高められます。
Pythonサービスは軽量な処理や新規機能を担当し、Javaサービスは既存ロジックや重い処理を担います。言語ごとに得意領域が異なるため、“Pythonはスピード、Javaは安定性” という役割分担が自然に生まれます。ECSではサービス単位でスケール戦略を変えられるため、Pythonはオートスケールを積極的に使い、JavaはメモリやCPUを厚めに確保するなど、最適化がしやすいです。
また、API Gatewayのタイムアウトは最大29秒のため、Java側の処理が重い場合は注意が必要です。必要に応じて非同期化やキューイングを検討することで、全体の安定性を保てます。
Python ⇄ Java の連携フロー
このシステムでは、クライアントからのリクエストはまずAPI Gatewayに入り、ルーティングルールに基づいてPythonサービスへ送られます。Python側で前処理や軽量なロジックを実行し、必要に応じてJavaサービスへ内部APIとしてリクエストを送ります。
Python → Java の通信はVPC内で完結するため、外部に公開されず安全性が高いです。また、REST APIで統一することで、言語の違いを意識せずに連携できます。レスポンスはPython側で統合し、API Gatewayを経由してクライアントに返します。
このフローにより、既存のJava資産を活かしつつ、新規開発はPythonで高速に進める というハイブリッドな開発体制が実現できます。
実装例
Pythonサービスがオーケストレーション役となり、必要に応じてJavaサービスへ内部APIを呼び出す、FastAPIを使った最小構成の例を以下に記載します。
async with httpx.AsyncClient(timeout=5.0) as client:
java_res = await client.get(JAVA_ENDPOINT)
このように、Python側で非同期HTTPクライアントを使うことで、ECS間の通信遅延を検知しやすくなります。Java側はSpring BootでシンプルなRESTエンドポイントを用意しておけば良いです。
@GetMapping(“/process”)
public Map<String, Object> process() {
return Map.of(“status”, “ok”, “value”, 123);
}
この構成により、既存のJavaロジックを活かしつつ、新規機能はPythonで高速に開発できます。内部通信はVPC内で完結するため、外部公開の必要がなく、安全性も高いです。
タスク定義も以下に例を記載します。
“cpu”: “256”,
“memory”: “512”,
“portMappings”: [{ “containerPort”: 8000 }],
“logConfiguration”: {
“logDriver”: “awslogs”,
“options”: {
“awslogs-group”: “/ecs/python-app”
}
}
CPU・メモリは最小構成の 256 / 512 とし、FastAPIを8000番ポートで公開しています。
ログは awslogs ドライバで CloudWatch Logs に集約し、API Gateway → Python → Java の流れを追いやすくしています。
また、Javaサービスの内部APIを呼び出すために、環境変数としてエンドポイントを渡しています。
“environment”: [
{ “name”: “JAVA_ENDPOINT”, “value”: “http://java-service.internal/api/v1/process” }
]
このように、Pythonサービスがオーケストレーション役となり、Javaサービスを内部APIとして扱うことで、言語の違いを意識せずに連携できる構成になっています。
運用でつまづきやすいポイント
実際に構築してみて、特に注意が必要だと感じたのはPython → Javaのレスポンス遅延でした。Java側の処理が重い場合、Pythonの処理時間も連動して伸びてしまい、最終的にAPI Gatewayのタイムアウトに達するケースがあります。
この問題に対しては、以下の対策が有効でした。
・Java側の処理をプロファイリングしてボトルネックを特定
・ECSタスクのCPU/メモリを増強
・Python側でリトライ回数とタイムアウトを調整
・必要に応じて処理を非同期化し、キュー（SQS）を挟む
また、AWS X-Rayを有効化すると、API Gateway → Python → Java のどこで遅延が発生しているかが可視化され、原因特定が非常にスムーズになります。特にマイクロサービス構成では、「どこが遅いのか」 を見える化できるメリットが大きいです。
まとめ
AWS ECSとAPI Gatewayを組み合わせることで、PythonとJavaのサービスを疎結合に保ちながら、安全かつスケーラブルに連携させることができます。API Gatewayで入口を統一し、ECSでサービスごとにスケール戦略を分離することで、開発スピードと安定性の両立が可能になります。
今回紹介した構成は、既存のJava資産を活かしつつ、新規開発をPythonで進めたいケースに特に有効です。今後はStep Functionsによるワークフロー化や、Lambdaを組み合わせた非同期処理など、さらに柔軟な拡張も検討できるようになります！
