Flaskのパフォーマンスを最大化！重い処理を高速化するための適切なWSGIサーバーの選定と設定方法

WebアプリケーションとしてFlaskを採用するケースは多いものの、実運用フェーズに入ると必ず直面するのがパフォーマンスの問題です。
特にアクセス数が増加したり、バックエンドで重い処理（画像生成、外部API連携、大規模データ処理など）を扱うようになると、標準開発サーバーのままでは明確に限界が見えてきます。

本記事では、Flaskアプリケーションの処理性能を最大化するために重要となるWSGIサーバーの選定と適切な設定方法について、コンピューターサイエンスの観点から整理していきます。
単に「Gunicornを使う」「uWSGIにする」といった表層的な話ではなく、プロセスモデルやスレッドモデル、I/Oバウンド・CPUバウンドの特性まで踏み込みながら解説します。

特に以下のような課題を抱えている場合には、本記事の内容が直接的に役立ちます。

• リクエスト数増加時にレスポンスが極端に遅くなる
• 重い処理が他リクエストをブロックしてしまう
• CPU使用率やメモリ使用量の最適化ができていない

Flaskは軽量で柔軟性の高いフレームワークですが、その性能はWSGIサーバーの設計に大きく依存します。
適切な構成を理解しないまま運用すると、アプリケーション自体の設計が良くてもスループットは簡単に頭打ちになります。

以降では、実際のユースケースを前提に、どのWSGIサーバーをどう選び、どのようなパラメータを調整すべきかを論理的に分解していきます。

Flaskアプリケーションのパフォーマンス問題と基本的な課題

Flaskは軽量で柔軟性の高いWebフレームワークとして広く利用されていますが、その設計思想ゆえにスケール時のパフォーマンスには明確な制約があります。
特にアクセス数が増加し、同時リクエスト数が一定の閾値を超えると、レスポンス遅延やスループット低下が顕著に現れます。

この章では、Flaskがなぜスケール時に性能劣化を起こすのかを、コンピューターサイエンス的な観点から整理します。

なぜFlaskはスケール時に遅くなるのか

Flaskのパフォーマンス課題の本質は、フレームワークそのものではなく、その実行モデルとWSGIベースの同期処理構造にあります。
Flaskは基本的にリクエスト単位で処理を同期的に実行するため、1つのリクエストが重い処理を抱えると、その処理が完了するまで他のリクエストが待機状態になります。

この挙動は、特に以下のようなケースで顕著です。

• 外部APIへのHTTPリクエスト待ち
• 画像処理やデータ集計などのCPUバウンド処理
• データベースクエリの遅延

これらはすべてI/O待ちまたはCPU占有時間の増大を引き起こし、結果としてワーカープロセス全体の占有時間を増加させる要因となります。

さらに、Flaskはデフォルトではシングルスレッド構成で動作することが多く、同時接続を効率的に処理する仕組みが標準では組み込まれていません。
そのため、以下のような問題が連鎖的に発生します。

問題	原因	影響
レイテンシ増加	同期処理モデル	リクエスト待ち時間の増加
スループット低下	ワーカー不足	同時処理能力の低下
リソース枯渇	長時間処理の蓄積	CPU/メモリ圧迫

また、Pythonのグローバルインタプリタロック（GIL）の存在も無視できません。
マルチスレッドを利用してもCPUバウンド処理では並列性が制限されるため、単純なスケーリングでは性能向上が頭打ちになります。

重要なのは、Flaskの遅延は「フレームワークの遅さ」ではなく、「実行モデルとワーカー設計の不適切さ」に起因するという点です。
この構造を理解せずにアプリケーションを拡張すると、リクエスト数の増加に対して直線的に性能が悪化する典型的なボトルネック構造に陥ります。

したがって次のステップとしては、WSGIサーバーのプロセスモデルやワーカー戦略を理解し、適切に構成することが不可欠になります。

WebアプリにおけるWSGIの仕組みと役割

Webアプリケーションのパフォーマンスや構成を正しく理解するためには、Flaskそのものではなく、その背後で動作しているWSGI（Web Server Gateway Interface）の役割を明確に把握する必要があります。
WSGIはPython製WebアプリケーションとWebサーバーの間に位置する標準インターフェースであり、リクエスト処理の責務を分離する重要な設計要素です。

この章では、WSGIがどのような仕組みでリクエストを処理し、Flaskとどのように連携しているのかを論理的に整理します。

WSGIとFlaskの関係性を理解する

Flaskはアプリケーションフレームワークとして、HTTPリクエストのルーティングやレスポンス生成を担当しますが、実際のリクエスト受信やプロセス管理はWSGIサーバー側が担います。
この分離構造により、Flaskはアプリケーションロジックに集中できる一方で、実行環境の設計がパフォーマンスに強く影響する構造になっています。

WSGIの基本的な処理フローは以下のように整理できます。

1. クライアントからHTTPリクエストが送信される
2. WSGIサーバー（例：GunicornやuWSGI）がリクエストを受信する
3. WSGIインターフェース経由でFlaskアプリケーションに処理が渡される
4. Flaskがルーティングとビジネスロジックを実行する
5. レスポンスがWSGIサーバー経由でクライアントへ返却される

この構造において重要なのは、Flaskはあくまで「アプリケーション層」であり、スケーリングや並列処理の制御はWSGIサーバー側の責務であるという点です。

特にパフォーマンスの観点では、WSGIサーバーの実装によって挙動が大きく変わります。
例えば、プロセスベースで並列処理を行う構成と、スレッドベースで処理を行う構成では、同時接続数やメモリ効率に明確な差が生じます。

要素	Flaskの役割	WSGIサーバーの役割
リクエスト処理	ビジネスロジック実行	受信・振り分け
並列性	直接制御しない	プロセス・スレッド管理
スケーリング	非対応	ワーカーモデルで対応

また、WSGIは同期的なインターフェースであるため、基本的には1リクエストごとのブロッキングモデルを前提としています。
このため、非同期処理を導入しない限り、I/O待ち時間がそのままスループット低下に直結します。

重要なのは、FlaskとWSGIサーバーを一体として捉えるのではなく、「アプリケーション層」と「実行基盤層」に分離して設計する視点です。
この構造理解が、後続のGunicornやuWSGIの最適化戦略を理解するための前提条件になります。

Gunicorn・uWSGI・mod_wsgiの特徴と比較

Flaskアプリケーションを本番環境で運用する際、WSGIサーバーの選定はパフォーマンスと運用コストの両面に直結する重要な意思決定です。
特に代表的な選択肢として挙げられるのが、Gunicorn、uWSGI、そしてApacheと連携するmod_wsgiです。
それぞれ設計思想や運用モデルが異なり、適切な理解なしに選定するとボトルネックの原因になります。

この章では、実運用の観点から各WSGIサーバーの特性を比較し、どのような状況でどれを選択すべきかを論理的に整理します。

Gunicornのシンプルさと実運用での強み

GunicornはPython向けWSGIサーバーの中でも特にシンプルな設計を持ち、運用のしやすさに優れています。
マスタープロセスと複数のワーカープロセスという明確な構造を持ち、設定項目も比較的少ないため、導入コストが低い点が大きな特徴です。

Gunicornの強みは、以下のような点に集約されます。

• 設定がシンプルで学習コストが低い
• プロセスベースの並列処理により安定したスループットを確保できる
• pre-forkモデルによりプロセスの独立性が高い

特に重要なのは、プロセス分離による障害耐性の高さです。
あるワーカーがクラッシュしても他のワーカーには影響が及ばず、マスタープロセスが自動的に再生成を行うため、運用上の安定性が確保されます。

また、CPUバウンドな処理に対してはワーカー数を増やすことでスケールアウトが可能であり、I/Oバウンドな処理ではスレッドワーカーや非同期ワーカーと組み合わせることで柔軟に対応できます。

一方で、機能面は必要最小限に絞られているため、高度なチューニングや細かい制御は外部コンポーネントに依存する設計になります。

uWSGIの高機能設定とチューニングの難しさ

uWSGIは非常に高機能なWSGIサーバーであり、単なるアプリケーションサーバーの枠を超えて、プロセスマネジメントやキャッシュ、ルーティング機能まで内包しています。
そのため、柔軟性と拡張性という点では他のWSGIサーバーを大きく上回ります。

しかし、その反面として設定の複雑性が極めて高いという特徴があります。

例えば、uWSGIでは以下のような要素を詳細に制御できます。

設定項目	内容	影響範囲
ワーカータイプ	prefork / async / threads	並列処理モデル
プロセス数	CPUコア数との関係	スループット
メモリ管理	リクエスト単位の制御	安定性
キャッシュ	内部キャッシュ機構	応答速度

このように細粒度の制御が可能である一方、適切なパラメータ設計を行わないと、逆にパフォーマンス劣化を引き起こすリスクも存在します。
特にメモリ設定やワーカープロセスのチューニングは、環境依存性が高く、経験的な調整が必要になるケースが多いです。

そのためuWSGIは、理論的には非常に高性能であるものの、運用難易度が高く、チームの運用成熟度によってはGunicornの方が実用的な選択肢となる場合も少なくありません。

Gunicornにおけるワーカー数とスレッド設定の最適化

Gunicornを用いたFlaskアプリケーションの運用において、最もパフォーマンスに直結する要素の一つがワーカー数とスレッド設定です。
これらのパラメータは単なるチューニング項目ではなく、システム全体の並列性モデルを決定する重要な設計変数です。

適切な設定を行わない場合、CPUリソースの過剰消費やスループット低下、さらにはリクエストのキュー詰まりといった問題が発生します。
そのため、ワークロード特性を正しく分類した上で構成を決定する必要があります。

CPUバウンドとI/Oバウンドに応じた構成戦略

Webアプリケーションの負荷は大きく「CPUバウンド」と「I/Oバウンド」に分類できます。
この分類はGunicornの設計を最適化する上での基礎となります。

CPUバウンド処理は、画像処理やデータ圧縮、機械学習推論など、計算資源を大量に消費する処理を指します。
この場合、スレッドによる並列化はPythonのGIL（Global Interpreter Lock）の影響を受けるため効果が限定的です。
そのため、基本戦略はプロセス数を増やすことになります。

一方でI/Oバウンド処理は、データベースアクセスや外部API呼び出しなど、待機時間が支配的な処理です。
この場合はスレッド数を増やすことで効率的にリソースを活用できます。

以下に典型的な構成方針を整理します。

処理タイプ	推奨構成	理由
CPUバウンド	ワーカー数 = CPUコア数に近い値	並列プロセスでGILを回避
I/Oバウンド	スレッドワーカー併用	待機時間を他リクエストで活用
混合型	プロセス + スレッドのハイブリッド	バランス型最適化

Gunicornでは通常、ワーカー数は「(2 × CPUコア数) + 1」を基準とする経験則が知られていますが、これはあくまで汎用的な目安です。
実際の最適値はアプリケーション特性やメモリ制約によって変動します。

また、スレッドを導入する場合は1ワーカーあたりのスレッド数とのバランスも重要です。
スレッドを増やしすぎるとコンテキストスイッチが増加し、逆に性能低下を招くことがあります。

重要なのは、単純なスケールアップではなく、処理特性に基づいた並列モデルの設計です。
これを誤ると、CPU使用率が高いにもかかわらずスループットが伸びない、あるいはメモリだけが圧迫されるといった非効率な状態に陥ります。

したがって、Gunicornの最適化は静的な設定作業ではなく、実際の負荷プロファイルを前提とした動的な設計プロセスとして扱うべきです。

uWSGIの詳細設定とパフォーマンスチューニング

uWSGIはWSGIサーバーの中でも特に高機能かつ柔軟性の高い実装であり、Flaskアプリケーションの本番運用において極めて強力な選択肢となります。
しかし、その性能を最大限引き出すためには、単純な起動設定では不十分であり、プロセス管理とメモリ最適化を含めた包括的なチューニングが必要になります。

uWSGIは内部に独自のプロセスマネジメント機構を持ち、リクエスト処理、ワーカー制御、メモリ監視などを統合的に扱います。
このため、設定次第でスループットと安定性の両方が大きく変化します。

プロセス管理とメモリ最適化の実践

uWSGIにおけるプロセス管理の基本は、preforkモデルを中心としたワーカープロセスの制御です。
このモデルでは、マスタープロセスが複数のワーカーを生成し、それぞれが独立したリクエスト処理を行います。
これにより、1つのワーカーがクラッシュしても全体への影響を局所化できます。

しかし、この構造を適切に設計しない場合、メモリ使用量が急激に増加する問題が発生します。
特にPythonアプリケーションでは、各ワーカーが独立したメモリ空間を持つため、ワーカー数の増加に比例してメモリ消費が増大します。

そのため、実運用では以下のような観点で調整を行います。

• ワーカー数はCPUコア数とメモリ容量のバランスで決定する
• max-requestsを設定し、ワーカーの定期的な再起動でメモリリークを抑制する
• lazy-apps設定によりアプリケーション初期化の最適化を行う

特に重要なのはmax-requestsによるリサイクル戦略です。
長時間稼働するワーカーはPythonオブジェクトの蓄積により徐々にメモリ使用量が増加する傾向があり、これを放置すると最終的にOOM（Out of Memory）に至る可能性があります。
そのため一定リクエスト数ごとにワーカーを再起動することで、メモリ状態をリセットする設計が一般的です。

また、メモリ最適化の観点ではアプリケーション初期化タイミングも重要です。
lazy-appsを有効化することで、各ワーカーがフォーク後に個別にアプリケーションをロードするため、コピーオンライトの恩恵を最大化できます。
これにより、初期メモリ消費を抑えつつスケーラビリティを向上させることが可能です。

設定項目	効果	注意点
workers	並列処理能力向上	メモリ消費増加
max-requests	メモリリーク防止	再起動オーバーヘッド
lazy-apps	起動最適化	初回リクエスト遅延

さらに、uWSGIはキャッシュ機構やルーティング機能も備えているため、単なるWSGIサーバー以上の役割を持ちます。
しかし、それらの機能を過剰に利用すると構成が複雑化し、デバッグ性が低下するため、必要最小限の構成で始めることが推奨されます。

最終的に重要なのは、uWSGIを「万能なサーバー」として扱うのではなく、「調整可能な低レイヤー実行基盤」として理解することです。
この視点を持つことで、パフォーマンスと安定性の両立が可能になります。

非同期処理とイベント駆動型WSGIの活用

Flaskアプリケーションの性能最適化を考える際、従来のプロセス・スレッドベースの並列化だけでは限界に到達するケースがあります。
特にI/O待ちが支配的なワークロードでは、CPUリソースが十分に活用されないままリクエストが滞留し、結果としてスループットが低下します。

この問題に対処する手段として重要になるのが、非同期処理およびイベント駆動型WSGIサーバーの活用です。
これにより、従来の「リクエスト単位でブロッキングするモデル」から、「待ち時間を効率的に再利用するモデル」へと構造を転換できます。

geventやeventletによるスループット改善

非同期WSGIの代表的な実装として、geventやeventletが挙げられます。
これらはグリーンスレッド（軽量ユーザースレッド）とイベントループを組み合わせることで、I/O待ち時間を効率的に活用する仕組みを提供します。

従来のスレッドモデルでは、1リクエストが外部APIやデータベース応答を待っている間、スレッドはブロックされリソースを消費し続けます。
一方でgeventやeventletを用いると、I/O待ちが発生した時点で実行コンテキストが自動的に切り替わり、別のリクエスト処理へ即座に移行できます。

この仕組みにより、同一プロセス内で多数の同時接続を効率的に捌くことが可能になります。

モデル	特徴	適用領域
スレッドベース	OSスレッドによる並列化	CPU・I/O混在
プロセスベース	完全分離による安定性	CPUバウンド
グリーンスレッド	軽量イベント駆動	I/Oバウンド

特にWebアプリケーションにおいては、I/Oバウンドな処理が支配的であるケースが多く、データベースアクセスや外部API通信を多用する構成ではグリーンスレッドモデルが非常に有効です。

ただし注意点として、geventやeventletは「魔法の高速化手段」ではなく、あくまで協調的マルチタスクモデルである点を理解する必要があります。
CPUバウンド処理が混在する場合、イベントループ全体がブロックされる可能性があるため、設計段階で処理の分類を明確に行うことが重要です。

また、標準ライブラリの一部はそのままでは非同期対応していないため、monkey patchingによる置き換えが必要になる場合があります。
この点は利便性とトレードオフ関係にあり、運用時の挙動理解が不可欠です。

結果として、geventやeventletの導入は単なるパフォーマンス改善手段ではなく、アプリケーション全体の実行モデルを再設計する行為に近い性質を持ちます。
そのため、導入判断はワークロード特性とシステム要件を踏まえた上で慎重に行うべきです。

Docker・Nginxを含む本番デプロイ構成

Flaskアプリケーションを本番環境で安定稼働させるためには、WSGIサーバー単体の最適化だけでは不十分であり、インフラ全体のアーキテクチャ設計が重要になります。
特にDockerとNginxを組み合わせた構成は、スケーラビリティと運用性の両面で現在の標準的な選択肢となっています。

Dockerを利用することで、アプリケーション実行環境をコンテナ単位で統一でき、環境差異による不具合を排除できます。
また、CI/CDパイプラインとの統合も容易になり、デプロイの再現性が高まります。
一方で、単体コンテナ構成では外部からのトラフィック制御や負荷分散が不足するため、Nginxのようなリバースプロキシの導入が不可欠になります。

この章では、DockerとNginxを前提としたFlask本番構成における設計思想を整理します。

リバースプロキシとロードバランシング設計

NginxはWebサーバーとしてだけでなく、リバースプロキシおよびロードバランサーとしての役割を担います。
この構成により、Flaskアプリケーション（およびWSGIサーバー）への直接アクセスを遮断し、インフラ層でリクエスト制御を行うことが可能になります。

リバースプロキシ構成の基本的な利点は以下の通りです。

• クライアントとアプリケーションサーバーの分離によるセキュリティ向上
• SSL/TLS終端の一元管理
• 静的ファイル配信の高速化
• 複数アプリケーションへのトラフィック分散

特に重要なのはロードバランシング機能であり、複数のGunicornまたはuWSGIインスタンスに対してリクエストを分配することで、水平スケーリングを実現できます。

典型的な構成は以下のようになります。

コンポーネント	役割	特徴
Nginx	リバースプロキシ	リクエスト振り分け・SSL終端
Gunicorn/uWSGI	WSGIサーバー	アプリケーション実行
Flask	アプリケーション層	ビジネスロジック

Docker環境においては、各コンポーネントをコンテナとして分離し、Nginxコンテナが複数のアプリケーションコンテナへリクエストを転送する構成が一般的です。
この際、Dockerネットワークを利用することでコンテナ間通信を抽象化し、柔軟なスケーリングが可能になります。

また、ロードバランシングアルゴリズムとしてはラウンドロビンが基本ですが、セッション維持が必要な場合はIPハッシュやスティッキーセッションを採用することもあります。
ただし、ステートレス設計を前提とすることで、よりスケーラブルな構成を実現できます。

重要なのは、Nginxを単なる入口としてではなく、システム全体のトラフィック制御レイヤーとして設計することです。
この視点により、アプリケーション層とインフラ層の責務分離が明確になり、長期的な運用性と拡張性が大幅に向上します。

ベンチマークと監視による継続的な最適化

Flaskアプリケーションのパフォーマンスチューニングにおいて、WSGIサーバーの選定や設定最適化は重要な初期ステップですが、それだけでは十分とは言えません。
実運用環境では、トラフィックパターンやデータ量、外部依存サービスの応答時間が常に変動するため、静的な設定は短期間で陳腐化します。
そのため、継続的なベンチマークと監視によるフィードバックループを構築することが不可欠になります。

まずベンチマークの目的は、システムの最大性能を測定することではなく、現実的な負荷条件下での挙動を定量化することにあります。
例えば、単純なリクエスト応答速度だけでなく、同時接続数、エラー率、CPU使用率、メモリ消費量などを総合的に評価する必要があります。
これにより、単なる「速い・遅い」ではなく、ボトルネックの所在を特定できます。

代表的なベンチマーク手法としては以下のようなものがあります。

• ロードテストツールによる同時リクエスト生成（例：ab、wrkなど）
• シナリオベースのエンドツーエンドテスト
• I/O遅延を含む現実的な外部依存シミュレーション

これらを組み合わせることで、単純な理論値ではなく実運用に近い性能評価が可能になります。

次に監視の設計ですが、これはベンチマーク以上に重要な継続的プロセスです。
監視は大きく以下の3層に分解できます。

層	監視対象	目的
インフラ層	CPU・メモリ・ディスクI/O	リソース逼迫の検知
アプリ層	レイテンシ・エラー率	アプリケーション健全性
ビジネス層	リクエスト成功率・ユーザー操作	ユーザー体験評価

このように多層的に監視することで、単一指標では見えない問題を検出できます。
例えばCPU使用率が正常でも、特定エンドポイントのみ極端に遅延しているケースなどはアプリ層監視がなければ検知できません。

さらに重要なのがメトリクスの収集と可視化です。
PrometheusやGrafanaのようなツールを用いることで、時系列データとしてシステム状態を継続的に追跡できます。
これにより、負荷増加のトレンドや異常発生の前兆を早期に検知することが可能になります。

また、ログ分析もパフォーマンス最適化において重要な役割を果たします。
単なるエラーログではなく、リクエスト単位での処理時間や外部API応答時間を記録することで、ボトルネックの粒度を細かく分析できます。

最終的に重要なのは、ベンチマークと監視を「一度きりの作業」として扱うのではなく、継続的改善サイクル（PDCA）として組み込むことです。
具体的には以下のような流れになります。

1. ベンチマークで現状性能を測定
2. ボトルネックを特定
3. WSGI設定やアーキテクチャを調整
4. 再度ベンチマークで効果検証
5. 本番環境で監視を継続

このループを回し続けることで、Flaskアプリケーションは単なる初期性能ではなく、長期的に安定した高性能システムへと進化します。
特にWSGIサーバーのような低レイヤー構成要素は、運用データに基づく調整が不可欠であり、理論と実測の両輪で最適化する姿勢が求められます。

FlaskのWSGI最適化における総合的なまとめ

Flaskアプリケーションのパフォーマンス最適化をWSGIレイヤーまで含めて体系的に捉えると、その本質は単なるサーバー設定の調整ではなく、実行モデル全体の設計問題であることが分かります。
ここまで解説してきたように、Flask単体の軽量性は高い柔軟性を提供する一方で、スケーラビリティや並列処理の責務は完全にWSGIサーバー側に委譲されています。
この構造を正しく理解しない限り、どれだけアプリケーションコードを最適化しても、システム全体の性能は頭打ちになります。

まず重要なのは、WSGIサーバーの選定がアーキテクチャの出発点であるという点です。
Gunicornのようなシンプルなプロセスモデルは運用性に優れ、安定したスループットを提供します。
一方でuWSGIは極めて高機能であり、細粒度なチューニングが可能ですが、その分だけ設定の複雑性と運用負荷が増加します。
さらに非同期モデル（geventやeventletなど）を導入する場合は、従来の同期型設計とは異なる思考が必要になります。

次に重要なのは、ワーカー設計と並列性モデルの理解です。
CPUバウンド処理とI/Oバウンド処理を適切に分類し、それぞれに応じた構成を選択することが性能最適化の核心となります。
例えばCPU集約型処理ではプロセス数を基準にスケールさせる必要がありますが、I/O集約型処理ではスレッドやイベント駆動モデルを活用することで効率的なリソース利用が可能になります。
この判断を誤ると、CPU使用率が高いにもかかわらずスループットが向上しない、あるいはメモリだけが消費されるといった非効率な状態に陥ります。

また、本番環境においてはWSGIサーバー単体ではなく、NginxやDockerといったインフラレイヤーとの統合設計が不可欠です。
Nginxによるリバースプロキシ構成は、リクエスト制御やSSL終端、ロードバランシングを担い、アプリケーション層の負荷を大きく軽減します。
Dockerは環境差異を排除し、再現性の高いデプロイを実現する基盤として機能します。
これらを組み合わせることで、初めてスケーラブルなWebシステムが成立します。

さらに見落とされがちなのが、運用フェーズにおける継続的な最適化です。
ベンチマークと監視は一度実施すれば終わりではなく、システムの変化に応じて繰り返し実行されるべきプロセスです。
特にトラフィック増加や外部API依存の変動は、WSGI設定の最適解を時間とともに変化させるため、固定的なチューニングでは対応できません。

ここで重要な視点を整理すると、以下のようになります。

観点	重要ポイント	影響範囲
WSGI選定	Gunicorn / uWSGI / 非同期モデル	実行基盤
並列性設計	CPU・I/Oバウンドの分類	スループット
インフラ統合	Nginx・Docker構成	スケーラビリティ
運用最適化	監視・ベンチマーク	継続改善

最終的にFlaskのWSGI最適化とは、単一技術のチューニングではなく、アプリケーション層からインフラ層までを含む多層アーキテクチャ設計そのものです。
この視点を持つことで、初めて「遅いFlask」から「スケールするFlask」へと進化させることができます。
重要なのは、個別最適ではなく全体最適を常に意識することです。