こんにちは。株式会社パイプラインの濱田です。

クラウド(IaaS)のサイジングについて、設計段階での考慮点をいくつか取り上げましたが、性能問題は往々にして実運用において顕在化します。今回は、運用フェーズにおけるサイジングのお悩みについて取り上げます。

スケールアップしたのに性能が改善しない

IaaS環境の運用において、インスタンスをスケールアップしたのに体感速度およびアプリケーション応答までの実測値が改善しない、という話はよく耳にします。

こうしたケースを相談された際に必ず「スケーリングの他に何か試しましたか？」とヒアリングするのですが、スケールアウト、スケールアップの操作はするものの

1. ミドルウェアの設定やOSのパフォーマンスチューニングをしていない
2. そもそも性能テストをしていない

大体こうした回答が帰ってくるのです。

これでは、IaaSのメリットを充分に活かしきれているとは言えません。これがオンプレミスであれば、性能テストを行い、ボトルネックを特定して、パフォーマンスチューニングを行うのが自然なフローでした。

OSやミドルウェアの設定1つでインスタンスのサイズを変えずにパフォーマンスが向上したら、単純にコストメリットが上がります。オンプレミスと同様、1つのインスタンスをとことん使い倒すのに等しいとも言えましょう。

おおよそスケールアップしたのに性能向上しない場合、インフラの観点ではOSやミドルウェアの設定変更で改善することがほとんどです。

推測するな、計測せよ

これは、安易にスケーリングするな、ということでもあるのですが、OSやミドルウェアの設定、デプロイされたコードを安直に弄ることを薦めているわけでもありません。

オンプレミスの経験があるエンジニアならイメージしやすいかと思いますが、コンピュータの部品を思い出しましょう。
CPU、メモリ、ストレージ、ネットワーク・・・どこにボトルネックが生じているのか、まず特定しましょう。

また、サービスのデプロイ前には性能テストを実施しましょう。これも相談を受けて思わず閉口した事例ですが、性能テストをしていないのは論外として、

1. アプリケーションができてもいないのに性能テストをしていた (無意味)
2. とりあえず性能テストはしたけれども継続してモニタリングしていない

といったように、テストシナリオの妥当性に疑問が生じることもありました。

例えばWEBアプリケーションであれば、ユーザー操作の導線をシナリオにしてブラウザの開発ツールでタイムラインを見るだけでも、おおよその当たりを付けることは可能です。

そこから、時間がかかっている箇所の処理が静的なhtmlなのかアプリのロジックなのか、ストレージへの書き込みなのか、はたまたDBなどの外部アクセスなのか、といった切り分けを行います。

運用フェーズでの性能テスト手法 (例)

サービスのリリース前に充分な性能テストができればよいのですが、現実問題そうとも限りません。

それでは、サービス運用開始後に性能テストを行いたい場合はどうすればよいのでしょう。

その1つの例として、実際に動いている環境をまるっと性能テスト用にコピーします。
実際に動いているコードと同じもの、同じデータが乗った環境を性能テスト用として用意しましょう。
ボトルネック特定および改善手法が確立してしまえば、その環境は壊してしまえばよいのです。
これこそが、クラウドならではの利点だと思いませんか。

最後にお知らせです。
このコラムを掲載いただいている京セラグループのAltXはエンジニア未経験者を積極的に採用しています。
AltXは未経験者向けの研修が手厚い事でも知られています。

AltXへの入社に興味がある方は、以下のURLにある技術キャリアセミナーで、入社後の研修やお仕事など、個別に質問できますので、実際にお話を聞いてみるとよいと思います。興味がある方は以下をご覧の上、是非ご参加ください。
https://www.altx.co.jp/careetec/seminar/tokyo/