拡張の準備
"準備が成功の鍵である" という格言を聞いたことがあるでしょう。 この格言は、成長を確実かつスムーズに成功させる場合に特に当てはまります。
クラウド コンピューティングの最大の利点の 1 つは、スケーリングできることです。 この機能により、一部で、クラウドは無限のスケーリングできるため、クラウドでの成長に向けた準備や計画は必要がないという誤った思い込みが生じています。
アプリケーションの要求を満たすのに十分なリソースがクラウドに存在する可能性が高いことは事実です。 ただし、依然として、必要な容量を把握することが重要である理由がいくつかあります。
ニーズを満たすのに十分なリソースがクラウドに存在する可能性は高くても、使用するすべてのサービスが自動的にスケーリングする、または本質的にスケーラブルであるとは限りません。 そのため、サービスの制限を認識し、サービスとリソースのスケールアップが必要になる時期を知っておく必要があります。
クラウド リソースは無限であるとしても、予算はそうではないでしょう。 コストを考慮する必要があります。また、財務部門の友人は、予測されるクラウド支出を知りたいと思っています。
有機的成長の計画
ビジネスの世界における有機的成長 とは、組織がその内在するリソースとスキルを活かし、ゆっくりとした自然な成長によってそのキャパシティを拡張するプロセスを指します。
ビジネスの有機的成長に合わせてクラウドの容量を計画するには、まず、アプリケーションの大規模なコンポーネントについて現在のリソース要件を緻密に計画する必要があります。
シナリオ: 有機的成長
このモジュールで前に確認したアーキテクチャに戻りましょう。 Tailwind Traders 社は革新的な新しい製品を立ち上げようとしており、結果として劇的な成長を予測しています。 なお、アーキテクチャの図は次のようになります。
容量計画を開始するには、大規模なコンポーネントを特定する必要があります。 この例では、次のコンポーネントが含まれています。
- Azure Kubernetes Service クラスター
- Azure App Service で実行されている Rewards アプリ
- Cosmos DB、Azure SQL などのさまざまなデータベース。
今後の使用量の計画に役立てるために、これらの大規模なコンポーネントについて、それぞれの現在のリソース使用量を把握しておく必要があります。 では、これらの大規模なコンポーネントの 1 つについてリソース使用量を見てみましょう。
Cosmos DB の容量を測定する
Cosmos DB では、ストレージはギガバイト単位で測定され、自動的にスケーリングされます。ただし、コスト上の理由から測定値を認識しておく必要があります。
スループットは事前にプロビジョニングされており、このスループットを測定するには "要求ユニット" と呼ばれるメトリックが使用されます。 要求ユニット (RU) は、メモリ、CPU、IOPS の組み合わせであり、容量の計画で利用できる 1 つのメトリックを提供します。 RU は、100 RU/秒の増分でプロビジョニングします。
すべての DB 操作は RU/秒で測定されます。 読み取り操作の場合は簡単です。1 KB の読み取りが 1 要求ユニットです。 その他の操作は、項目のサイズ、データの整合性、クエリ パターンなど、複数の要因に基づいて計算されます。
アプリケーションのプロファイリングを行うとき、Cosmos DB からのすべての応答には要求の使用量ヘッダーが含まれており、その要求で使用された RU の正確な数が示されています。 使用されている RU の数を、プロビジョニングされている数と比較して、現在の容量が不足していないかどうかを確認できます。
リソースの使用状況を、月間アクティブ ユーザー数や収益などのビジネス メトリックに関連付けることをお勧めします。 この関連付けは、ビジネスの成長予測に基づいて容量を計画するのに役立ちます。 これらの容量メトリックは Azure Monitor で取得できます。 システムのリソース使用量を把握すると、スケールアップが必要になる時期と、時間の経過に伴うコストを認識するのに役立ちます。
Tailwind Traders 社の CosmosDB の使用状況のデータを具体的に見てみましょう。 使用状況のグラフを次に示します。
この例では、Tailwind Traders 社の月間アクティブ ユーザー (MAU) は平均で 2,500 増加しており、現在のユーザー ベースは 10,000 です。
ストレージを見てみると、データベースでは使用可能な 5 TB のうち 300 GB (6%) が使用されており、 毎月 50 GB (1%) ずつ増加していることがわかります。
スループットの観点からは、現在は 300/1000 にあり、10%/月で拡大しています。
システム リソースのメトリックを把握したので、スループットのスケーリングが必要になる可能性がある時期と、時間の経過に伴うコストがわかりました。
これで、容量計画に役立つグラフを作成できるようになりました。
5 月にはデータベースの RU の容量に到達することがわかったので、その前にスケーリングする必要があります。 もう 1 つの興味深い分析情報は、事前にプロビジョニングされた容量近くまで使用されていないため、現時点では CosmosDB データベースをスケール ダウンできる可能性もあるということです。
無機的成長の計画
前の例では、有機的な成長を計画していました。 無機的成長は、会社自体のビジネス アクティビティの増加ではなく、外部の要因によって生じます。 自然な進行ではなく、使用量が急激に増加する傾向があります。
トラフィックやユーザーなどの増加について実際に事前に把握できていない場合もあります。 このような場合を見越して、可能な限り自動的にスケーリングでき、それが不可能な場合には適切な形で失敗するようにシステムを構築する必要があります。 それについては、このモジュールで後ほど説明します。
それ以外の場合は、製品の発売が近いときなどに無機的成長が生じる可能性があり、それに向けた計画と準備を行うことができます。 チームがエンジニアリング、製品、マーケティング、財務にわたって共同作業を行う場合、リソースの使用状況と成長パターンがわかっていれば、 相応の作業で、これらのイベントがリソースの要件に与える影響を予測し、それに応じて変更を実装することができます。
これがうまくいくかどうかは、組織やイベントによって異なります。 必ずしもうまくいくとは限りませんが、できる限り準備をしておくことで、有利なスタートを切ることができます。
シナリオ: 無機的成長
無機的成長の計画の例として、別の仮定の状況を見てみましょう。 Tailwind Traders 社では、注目を集める革新的な新製品を発売するためのマーケティング イベントが近く予定されています。 それによって、販売サイトにアクセスするユーザーが 5000 人増加すると見込んでいます。
前に示した有機的成長の例のデータを使用して、それを (できれば因果関係と共に) 製品/マーケティング チームから取得したビジネス メトリック (ユーザー数など) に関連付ければ、 無機的成長の計画を開始できます。
前のシナリオから、2500 ユーザーあたりストレージが約 50 GB で、RU が 100 であることがわかります。 このデータを使用して、このイベントの準備ができているかどうかを判断できます。 5000 ユーザーが見込まれる場合、100 GB のストレージと 200 RU/秒が必要になります。
これらのストレージ容量は、イベント後の予想される増加に対して十分であることがわかります。 これらの容量は自動的にスケーリングされるため、新しいコストを把握することを除いて、心配はありません。コストの把握については後ほど説明します。
また、RU は、イベント後も容量の 50% にしか達しないと予測することもできます。 そのため、このイベントで Cosmos DB の容量に関して心配はありません。
ただし、コストへの影響はあります。
100 GB の追加ストレージによって 25 ドル/月の追加コストがかかることがわかります。 スループットの料金はプロビジョニングされた RU に対してお客様が支払っているものと同じで、既に十分なスループットです。 要するに、このマーケティング イベントによって CosmosDB の請求額が $25 米国ドル増加すると見込まれます。