Djangoで動くシステムをオンプレミスからクラウドへ移行しようとしたとき、アプリケーション自体の移植はさほど難しくない。問題は移行後の「運用設計」が後回しになり、本番障害が起きてから慌てるケースだ。
Djangoは2003年、米国の新聞社Lawrence Journal-Worldの内部ツールとして生まれ、2005年にオープンソース化された。Python製のフルスタックWebフレームワーク（Web開発に必要な機能を一式備えた開発基盤）であり、ORM（オブジェクトリレーショナルマッパー：PythonコードでSQLを書かずにDBを操作できる仕組み）・認証・管理画面・フォーム処理をデフォルトで持つ。Instagram・Pinterest・Disqusといった大規模サービスの基盤としても採用実績があり、日本国内でも業務システムやAPIサーバーとして広く使われている。
MVTアーキテクチャと監視設計の接点
DjangoはMVT（Model・View・Template）というアーキテクチャを採用している。Model がデータベース構造を定義し、View がリクエストを受け取ってビジネスロジックを実行し、Template が結果をHTMLで返す、という3層構造だ。この構造はクラウド移行後の監視設計に直接影響する。
View層はHTTPリクエストを処理するため、レスポンスタイムの計測ポイントになる。たとえばAWS環境であればALB（Application Load Balancer）のアクセスログとCloudWatch Metricsを組み合わせることで、View単位のレイテンシ（応答遅延）を可視化できる。一方でModel層のORM経由のSQLは、クエリ数が増えやすい「N+1問題」（1件取得するたびに追加クエリが発行される非効率なDB呼び出し）を起こしやすい。オンプレではリクエスト数が少なかったため表面化しなかったクエリ問題が、クラウド移行後にアクセス集中で一気に顕在化するパターンは珍しくない。
Djangoにはデバッグ用のdjango-debug-toolbarというライブラリがあり、開発環境でView単位のSQL発行数を確認できる。ただし本番環境での監視には別途APM（Application Performance Monitoring：アプリケーションの処理性能を継続的に計測するツール）が必要になる。DatadogのDjangoインテグレーションやNew Relicのエージェントを導入すれば、View単位のトレース（処理の流れを追跡すること）とDBクエリのボトルネック特定が自動化される。
クラウド移行パターン：Lift & Shift vs 設計見直し
Djangoアプリをクラウドへ移行する際、よく取られるアプローチは大きく2つある。
- Lift & Shift（リフト＆シフト）: オンプレの構成をほぼそのままクラウドのVMに乗せ換える手法。移行コストは低いが、オンプレ時代のセッション管理やファイルアップロード先のローカルパスなどがクラウド環境に合わず、障害の原因になりやすい
- コンテナ化 + マネージドサービス活用: DjangoアプリをDockerコンテナに収め、DBはRDS（AWSのマネージドRDB）、静的ファイルはS3に分離する構成。運用負荷は下がるが、設定変更の範囲が広い
Lift & Shiftで頻発する問題の一つが、Djangoのセッションバックエンド設定だ。デフォルトではセッション情報をDBに保存するが、複数インスタンス構成（オートスケーリング環境）では同じユーザーのリクエストが別のインスタンスへ振り分けられることがある。この場合、セッションバックエンドをElastiCache（AWSのマネージドRedis）に切り替えることで解消できる。設定は settings.py の2行変更で済むが、見落とすと認証切れが頻発して原因特定に時間がかかる。
# settings.py のセッション設定例
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
SESSION_CACHE_ALIAS = 'default' # ElastiCacheをDjango CACHES設定に追加する障害の根本原因分析：ログ設計が決め手になる
クラウド移行後の障害対応で差が出るのは、ログの設計だ。DjangoはPythonの標準loggingモジュールを使っており、settings.py のLOGGING設定でログの出力先・フォーマット・レベルを細かく制御できる。
オンプレ時代はサーバーのローカルファイルにログを書き出していたケースが多い。クラウドへ移行したら、標準出力（stdout）へ出力先を切り替え、CloudWatch LogsやGCPのCloud Loggingへ集約するのが定石だ。ログをJSON形式にしておくと、CloudWatch Logs Insightsでのクエリが容易になる。たとえば logger.error() で出力した例外スタックトレースをJSON化しておけば、fields.level = 'ERROR' で絞り込んで障害発生時刻を特定できる。
DjangoのORMが発行する遅いSQLを見つける場合は、RDSのPerformance Insightsと組み合わせるのが効率的だ。実行時間上位のSQLを特定し、DjangoのModel定義に戻って select_related()（外部キーを結合クエリで取得するメソッド）や prefetch_related()（多対多関係を別クエリでまとめて取得するメソッド）を追加すると、N+1問題を修正できる。
運用コストの観点では、常時稼働のEC2インスタンスよりもコンテナをECS Fargate（サーバー管理不要でコンテナを実行するサービス）で動かすほうが、トラフィックの少ない時間帯のコスト削減につながる。ただしコールドスタート（コンテナ起動時間）がレスポンスタイムに影響するため、最小タスク数の設定は監視データを見ながら調整が必要になる。
Djangoはフレームワーク自体の成熟度が高く、クラウド環境への適合も難しくない。移行の成否を分けるのは、アプリコードよりも監視・ログ・セッション管理といった運用基盤の設計精度だ。