こんにちは、サイオステクノロジーの前田です。

アプリケーションを運用するときに、小規模以上の場合は性能設定を考える必要が多くあります。小規模だとリソースを使い切っていないため問題はないのですが、規模が大きくなると適切なリソース設定が必要になります。リソースの設定がうまくいっていない場合としては、メモリは足りないがCPUに余裕がある状態、アプリケーションの同時接続数が足りなくてレスポンスが悪くなる等、リソース設定が適切でないと期待する性能が出ない状態になっている場合があります。それはサービス提供側としては望ましくない状態です。

性能試験を実施し判別する方法もありますが、各パラメータを一つ一つ変更して調査するには膨大な労力と時間がかかります。そのため試験を行わないでリリースすることも多くあります。

Kubernetes環境でもいろいろなリソース設定があります。その中でもコンテナのCPUとメモリに関しては、リクエスト値が大きいと無駄にコストがかかる原因になります。多くのコンテナを利用する場合には、サービスを提供するという『性能観点』以外にも『コスト観点』で調整するという重要な項目でもあります。

本日は機械学習を利用してパフォーマンスチューニング等を簡易にできるStormForgeについてお話ししていきます。

Kubernetesのサイジングなど

コンテナアプリケーションのサイジングについて

Kubernetesのアプリケーションのサイジングを行う個所は複数あります。下記図に主なパフォーマンスチューニングの箇所を記載しました。クラスターに関するパフォーマンスチューニングのノードプールや動的ストレージ等は除いています。

• パフォーマンスチューニングの主な内容
  • コンテナ
    • リソース必要量（request)
    • リソース制限量（limit)
  • 設定していないコンテナのリソース設定（Namespace範囲）
    • デフォルトリソース必要量
    • デフォルトリソース制限量
  • ネームスペースのリソース制限
    • Namespaceで利用できる合計CPU容量
    • Namespaceで利用できる合計メモリ容量
    • Namespaceで利用できる合計Pod数量
    • Namespaceで利用できる合計ストレージ容量
  • Podのオートスケーリング設定
  • コンテナの中のアプリケーションの環境変数
    • 例）javaのヒープサイズ

詳細はKubernetesの公式ドキュメントを確認していただき、ここでは重要なポイントを記載していきます。

■必要リソース量(request)が実使用量より差異がある場合の無駄

★必要リソースが多い場合

Kubernetesのリソース必要量は、コンテナの実利用料が下回っても確保され続けています。正確にはリソース必要量の合計値がノードを上回ったときにPod等のワークロードがデプロイできなくなります。

例）32GBのメモリをもつノードに、実際は0.1Mbのメモリしか使用しないがリソース必要量で2GBの設定をしているコンテナだと、最大16（簡易計算）個しかデプロイできなくなります。本来は320個のコンテナがデプロイ可能なのに、16個しかデプロイできない状態で無駄にリソースを使用してます。コンテナ自体は無料でもノードのリソースを無駄に使用してしまい余分なコストがかかってしまいます。

★必要リソースが少ない場合

初期からリソースを多く使用するアプリの場合リソースが足りなくて初期起動が失敗しコンテナが利用できない状態（コンテナの再起動が続く状態）になる場合があります。

■制限量(limit)と差異が大きい場合のサービス品質低下の問題

★制限量が少ない場合

制限量を超えてしまうと強制的にプロセスが停止されるOOMでコンテナが落ちてしまいます。そのため処理途中で中断するようなことが起きてしまい応答速度が低下することが多くなります。

★制限量が多い場合

制限量を高くした場合、一つのコンテナがリソースを使用しすぎて同一ノード上に存在する他ののコンテナのリソースが不足しサービスに影響する事態が発生する場合があります。

性能試験について

性能設定は、DBやJAVAのアプリケーション等で昔から多くおこなってました。性能を決めるための性能試験を行う場合、プロダクション環境を想定したアクセス数量やパラメータ設定を少しずつ変更して試験を行っておりました。

性能試験の場合はある程度時間をかけて実施します。性能試験のために負荷をかける必要もあり、場合によっては専用の負荷をかけるサーバも必要でした。試験内容も数時間かけて実施し、少しずつ設定変更して再度試験を行う。そのような、試験の中でも一番時間と負担が大きい試験の一つでした。

StormForgeについて

StormForgeの製品は機械学習を利用して簡易に試験＆設定＆提案してくれるものです。今年2月にはOptimize liveがリリースされたため、大きく分けて2つの製品になりました。それぞれ用途や利用料金が違うため本記事で説明していきます。

Stormforgeリンク

Optimize Pro　（＋PERFORMANCE TESTING）

こちらは、性能試験のPERFORMANCE TESTINGを利用しながら、ノンプロダクション環境で性能やパラメータを決めるために使用されるものです。チューニング箇所はいろいろな個所を設定することができます。

下記のサンプル画像は性能試験後の結果の画像になります。性能試験は、設定した後パラメータを自動的に変更しながら自動的に試験を行い、グラフ表示と推奨値を出してくれます。機械学習を利用して推奨値を出してくれます。そしてマニフェストファイルの変更するための情報をpatch情報を表示してくれます。

縦軸に 95%Latency 横軸にcostで表示されたグラフです。このグラフと結果のパラメータから推奨値を決めることができます。

■パッチサンプル

{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"name":"redis-cart","namespace":"default"},"spec":{"template":{"spec":{"containers":[{"name":"redis","resources":{"limits":{"cpu":"35m","memory":"157Mi"},"requests":{"cpu":"35m","memory":"157Mi"}}}]}}}}

上記パッチを充てることでマニフェストファイルをアップデートできます。

参考情報: Kubernetesのpatchについて

■　Optimize Proの主な利用用途としては、

性能試験とパラメータチューニングになります。

PERFORMANCE TESTING（性能試験）

グローバル環境から性能試験（HTTP）アクセスを行うツールがOptimize Proには付属しております。こちらはHarファイル等を利用して性能試験を行うものです。どれぐらいのリクエストを送るか等の設定も行いやすく結果の表示も理解しやすいものとなっています。

Optimize Proを利用しなくても単独で試験として利用することも可能です。

StormForge構成

構成に関して、私が簡易試験を行ったころ下記のような構成になっております。テストツールは外部にあるためリソース消費は少なく利用することがでできます。Optimize LiveとProは別々のコンテンツなのですが、同じところにデプロイすることができます。利用しないときはポッドの数を０にするという方法で停止可能です。

Optimize live

  こちらはメトリックスデータ（promeheusやdatadogに収集されたデータ）から推奨値を作成するものです。Optimize Proと違い複数のパラメータチューニングの推奨値表示はできません。コンテナのCPUとメモリのrequestとlimitが現バージョンのチューニング内容となります。バージョンアップも行われているので他のパラメータに関しても今後対応される可能性は高いです。

上記以外に、ptimize Liveにはgrafanaが内部に存在するためgrafanaの内容を見ると直観的に理解しやすいです。機械学習のためには2週間以上のデータがあることが好ましいです。

■利用用途として

プロダクション環境で利用して、最適なリソースに手動もしくは自動で設定をする用途で主に使います。

商品比較

※アプリケーション単位とはNamespace毎か、Namespaceでラベル設定範囲になります。ライセンスの詳細な問い合わせは別ページからお問い合わせください。

StormForge参考動画

StormForgeの内容が動画で公開されています。ぜひご覧ください。

OPTIMIZE LIVEのデモ

PERFORMANCE TESTINGのデモ

OPTIMIZE LIVEの動画

おわりに

性能試験は、大事な試験ではありますがとても大変で難しい試験の一つです。バージョンアップや連携が複雑になれば昔ながらの一つ一つ確認していく方法だと現実的でない場合も増えてきています。そのため、トライアル版を解放しての調整や自動化して試験するケースが増えています。Stormforgeは性能試験をしないような小さな環境ではコストが高く感じるかもしれませんが、パラメータチューニングが必要な環境の場合には試験にかかわるコスト（準備コスト、試験コスト）等も大幅に削減されます。性能を適切にすることで、Kubernetesのランニングコストを抑えることができるのも大きな魅力です。トライアルもあるため、まずは利用してみてください。本内容がKubernetsで悩まれている問題の解決の一つになれば幸いです。

About 前田周哉 29 Articles

血液はみかん色。インフラを中心に対応、認証、DB、API、コンテナ基盤,クラウド、iotなど複数のシステムインフラを対応するサーバエンジニア。現在はOpenShift中心にkubernetesに関連する対応が中心。

Twitter YouTube