AWSパフォーマンス効率化のために何を減らし増やすか

AWSのパフォーマンス効率化のために何を減らし何を増やせば良いでしょうか。

結論から申し上げますと、ある4つを減らすために、ある4つのプロセスに沿って、ある4つの実行回数を適度に増やすことです。

目次はこちらになります。

トレードオフ（=Plan）
モニタリング（=Do）
レビュー（=Check）
選択（=Action）
まとめ

効率化とは費用対効果の追求です。つまり、最小限の労力と費用で、最大限にシステムへの負荷や障害を軽減させる継続的な取り組みになります。

先に挙げた「ある4つを減らす」とは、具体的に下記を指しますが、これを仮に「負の4大要素」と呼びます。

負荷を減らす
障害を減らす
負担を減らす
費用を減らす

次に、先に挙げた「ある4つのプロセス」とは、ITILのベストプラクティスでも紹介されている「PDCA」を指します。

Plan
Do
Check
Action

また、「ある4つの対策」とは、AWSが提唱するベストプラクティスのことですが、これを仮に、「効率の4本柱」と呼びます。別の呼び名で「パフォーマンス効率4つの柱」というのもあるそうです。

トレードオフ
モニタリング
レビュー
選択

先の「負の4大要素」を減らすために「PDCA」のサイクルに沿って「効率の4本柱」を実行する回数を適度に増やせば、AWSのパフォーマンス効率化を実現してくれます。

効率化は費用対効果の追求であるため、「負の4大要素」を減らす事が、そのまま効率化を意味します。つまり、目的は「負の4大要素」を減らす事、「PDCA」のサイクルに沿って「効率の4本柱」を実行する事が手段です。

なぜ、このサイクルに沿って実行すると「負の4大要素」を減らすことができるのか。

ビジネスと密接に関わる、自社特有の負荷特性を把握できる上、AWSの強みを最大限に活かすことができるからです。ここでいう、AWSの強みとは、同社が提供する、最新のテクノロジーとアプローチを指しています。

例えば、今後の商品・サービスの拡販を狙う企業が、以下の要件を持っているとします。

▼ビジネス要件

ある商品・サービスのプロモーションを行う
初期投資はなるべく抑えたい

▼システム要件

サービスの遅延や停止をなくしたい
柔軟なインフラ設計にしたい

この要件を満たすために、どう「PDCA」のサイクルに沿って「効率の4本柱」を実行し「負の4大要素」を減らすか。まずは、下記の、「PDCA」と「効率の4本柱」の関係をご覧ください。

f:id:vtaiki:20200314174656p:plain

実は、PDCAの各プロセス（Plan / Do / Check / Action）を効率の4本柱に当て込んだだけです。。では、順に説明します。

トレードオフ（=Plan）

トレードオフとは、何かを選び何かを捨てる相容れない関係のことです。可用性か、性能か、または料金か、何を重視するか優先順位を定め、要件を満たすための具体的な目標を立てます。

「戦略の立案」では、ビジネス要件やシステム要件に基づき、あるべき姿を設定します。ここでのあるべき姿を、「プロモーションで増加するサイトへのアクセス数を、低レイテンシで捌ける性能と高可用性を持つシステム」と定義します。

具体的には、CSF（成功要因）とKPI（測定基準）を設定し、優先順位を決めます。

このCSFとKPIは、先の要件を満たすための「目標」です。

例えば、CSFは「性能の強化」「可用性の確保」、KPIは「アクセスピーク時に3秒以内にWebサイトのページを表示させる」、「24時間365日のサイト無停止で維持する」等です。(この目標だと費用の爆上げが容易に想像できますが。。)

「対象の設定」では、設定したKPIに関係するメトリクスを測定対象にします。例えば、アクセス数や応答時間、障害件数、CPUやパフォーマンス使用率、運用保守にかかる時間、リソースにかかる料金などです。

モニタリング（=Do）

ここでは、先の「対象の設定」で決めた、測定対象の生データを集め、そのデータを加工し、判別可能な情報に変換します。

「データ収集」では、誰が、いつ、どのくらいの頻度、どのくらいの期間に渡って監視するかがポイントです。

「データの処理」では収集した、先のKPIに関係するメトリクスを抜き出し、次のフェーズで分析しやすいように加工・整形します。

レビュー（=Check）

レビューでは、収集した情報を分析し、負荷の特性を掴み、有効な対策を検討します。

「情報の分析」では、前プロセスで加工した情報を分析し、負荷の特性を掴み、先の目標を阻む原因を絞り込みます。この辺りから、夜間の処理でレイテンシが悪化する、週末にアクセスが集中しサーバーに過負荷がかかる等、自社特有の傾向が見え始めます。

ボトルネックの特定は、クライアント側に近いレイヤーから原因を絞ることです。

ネットワークのトラフィックから調査を始め、サーバーのスループット、アプリケーションやデーターベースのレイテンシに至ります。ツリーレイヤーをイメージすると、上位から下位のレイヤーにいくほど、枝分かれしていくため、クライアント側に近いレイヤーから調べていくと、原因が複数あるときにも見落とすリスクを減らせます。

WEBの3層構造で表現すると、原因の特定順はこのイメージです。

1.WEB → 2.APP → 3.DB

ちなみに、チューニングの順序はこのイメージです。

1.APP → 2.DB → 3.WEB

例えば、SQLが根本原因なのにメモリだけ拡張しても一時凌ぎです。再びキャパ不足に陥るでしょう。しかし、SQLのチューニングだけで問題が解消できれば、コストを抑えることができます。

「対策の検討」では、AWSの豊富なサービスや機能から、自社の課題にフィットしたソリューションを探し、うまく組み合わせます。

クラウドでは単体のサービスを採用するだけではあまり効果を得られません。

例えば、あるプロダクトでは、レイテンシ向上のためにAWS RDSを採用しましたが、それだけではレイテンシを改善できませんでした。複数のAZ(アベイラビリティーゾーン)を跨ぐマスターDBとスレーブDB間の同期が頻発していたため、同期の度に書き込みのリクエストが待機していたからです。

Bulk Insertの機能を使い同期処理の回数を減らしたところ、書き込み処理は劇的に改善しました。その上、RDS Performance Insights(パフォーマンスインサイト)を使うと、待機イベント単位のKPIを可視化でき、ボトルネックを特定しやすくなります。チューニング目標も設定しやすくなり、運用負担を減らす事ができました。

このように、他の機能を組み合わせたり、アプローチを変えることで少しずつ改善の目途が立ちます。

マスターとスレーブのDB両方を同じAZ内に配置すれば、もっと同期処理が早くなりますが、単一のデータセンターで障害が起きると可用性が損なわれます。そのため、AZを分けながらも低レイテンシで運用するプラクティスを追及します。

この処理速度や耐障害性を合わせもつことは、先述したトレードオフの状態と言えます。低レイテンシと高可用性、相容れないものを両立させたいとしたら、トレードオフの溝をどう埋めるべきか。

選択（=Action）

AWSの設計原則には、以下の5つがあります。

最新の標準化
レイテンシー
サーバーレス
実験
システムを深く理解

これらを一言でまとめると、「AWSの潜在能力を最大限に引き出すノウハウの最大化」です。

このノウハウの最大化こそが、トレードオフの溝を埋める方法です。

クラウドは初期コストが安価でキャパシティプラニングが不要と言われますが、システムの理解が不足していれば想定外の問題を引き起こします。運用コストが異常に高くなったり、CPUクレジットを超えたバーストインスタンスはパフォーマンスを劣化させます。

システムへの深い理解があってこそ、クラウドの強みを活かすことができます。

クラウドの大きなメリットは、低予算でスクラップ＆ビルドができることです。そのテストと実験も含めたPDCAの繰り返しが、負荷特性やシステムの理解を助け、ノウハウの最大化を実現してくれます。

そして、ソリューション選択の結果に応じて、目標のベースラインを見直し、PDCAのサイクルに沿って、継続的な改善を繰り返します。このサイクルを適度に増やせば、日々変化する負荷のパターンを早期に発見し、日々更新されるサービスの中から最適なソリューションを利活用して、パフォーマンスの効率化を追求できます。