アプリケーションを効率的に拡張する – 水平か垂直か?

生産用にアプリケーションを配置している方は、おそらく需要増加に応じた拡張の経験があることでしょう。一世代前の
アプリケーション拡張は、仮想化によるインスタンス数またはサイズの増加のみに単純化されていました。しかしクラウドの出現により、
理論上は無限に拡張できるようになりました。もしかしたら、CPU、ヒープ・サイズ、スレッド数等のような下層システムの指標に基づいて、自動拡張を
設定したこともあるかもしれません。今や問題は、「需要に合わせて自分の環境を拡張できるだろうか?」(可能であれば十分なコンピューティング資源を追加した場合
)から、「どうしたら効率的に自分のインフラストラクチャをトラフィックに対応させられるだろうか、そして幸運であれば、必要な時に圧縮できるだろうか
?」に移行しています。これはほぼ毎日、DevOps実施組織を相手にしている筆者が直面している問題です。
アプリケーション環境が以下のように見える場合(もしそうであれば、あなたになりたい):

Screen Shot 2015-03-17 at 10.57.36 AM

おそらく順を追って、最終的には解決策を見つけることができるでしょう。一連の負荷試験を行い、試験パラメータの性能に基づいて機械サイズのスイートスポットを見つけ、
生産インフラストラクチャに焼き込みます。CPU利用率が高い場合、各階層にインスタンスを
追加してください。簡単でしょう。もしあなたのアプリケーションがこのように見えたらどうなるでしょうか?

Screen Shot 2015-03-17 at 10.57.45 AM

アプリケーション・コードを変更した場合は?インスタンスを追加しても、それ以上問題を解決しなかったら?
(費用がかかり、紙幣はすぐに積み上がりますが…)
問題の複雑性は、CPUバウンディングが唯一のアスペクトであることにあります — 大抵のアプリケーションは拡張の際に様々なバウンドと出会い、
各階層によって異なります。インフラストラクチャの観点からすると、CPU、メモリ、ヒープ・サイズ、スレッド数、データベース接続プール、キューデプス等
が関与します。最終的に、問題は反応時間まで分解されます:
諸経費を最小限に抑えながら、毎回どうやってトランザクションを高性能なものにできるでしょうか?
ここで探し求める聖杯は、自身のアプリサーバのインスタンスの区分方法(適切なサイズ)、各レベルで生成する数(適切な規模)及び、生成する時期(適切な時期)を
動的に決定する能力です。インフラストラクチャのサポート、コードの問題、及びデータベースのような他の要因も同様に関与します。
しかし、それは改めてお話ししましょう。
簡単な例を挙げます。最近、生産環境を分析している顧客と仕事をしていたときに起こりました。軽負荷/常用負荷のアプリケーション段階を見ると、
拡張要因を決定するのが困難になりました。結論はこうです:

反応時間は実際、カーブの始まりに向かって減少します(恐らくキャッシング効果)。しかし、より重い負荷をかけたアプリケーションを見ると、
さらに興味深い結果が得られます。突然、アプリケーション需要が増加すると性能が影響を
受け始めるのです。

Screen Shot 2015-03-17 at 10.57.54 AM

このアプリケーションの重負荷期に関しては、反応時間が急増するにもかかわらず実際はハードウェア資源が依然として
多少安易に利用されます。

Screen Shot 2015-03-17 at 10.58.12 AM Screen Shot 2015-03-17 at 10.58.24 AM

このアプリケーションにおいて、実際には反応時間が他のハードウェア・バウンドよりも
ガベージ・コレクションと密接に相関しているのです。
ガベージ・コレクションの最適化に対しては、明らかに今後取り組みがなされますが、この場合、適合度の最適化は、
実際には望ましい反応時間の決定、その反応時間を維持するインスタンスサイズへの最大負荷、
そのインスタンスサイズの費用に及びます。クラウドのシナリオにおいては、インスタンス費用は通常容易に決定できます。この場合、垂直拡張において良いスイートスポットを決定するための、
様々なインスタンスサイズにおける量/(インスタンス費用)を計算することにより、これを標準化できます。
平行拡張は環境によって多少変動しますが、より線形になる傾向があります。すなわち、
各追加インスタンスがアプリケーションに増分処理能力を追加します。
依然としてこの問題には大いに分析の余地があります。個別トランザクションの資源費用、最適な反応時間対その反応時間を実現するための費用、
同期対非同期設計のトレードオフ等がそれに挙げられますが、環境によって変動します。
インフラストラクチャ指標よりもアプリケーション自身の性能指標(ガベージ・コレクション、反応時間、接続プール等)を使用することにより、最新アプリケーションがリリースされると素早く、
理性的にクラウドのインスタンスを正しいサイズにし、全体効率を向上するためコード最適化の領域を
決定することができました。コード最適化は将来を見据えたプロジェクトですが、
拡張に関する疑問は近々対処する必要がある出来事に対応するものでした。このように疑問に答えることにより、
間近に迫った期限に合わせて、最適化またはアプリケーションの変更に対して
十分な適応性を保つことができました。
どうやって環境を拡張できるか知りたいですか?無料トライアルで使用してみましょう!