いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！
OCI（Oracle Cloud Infrastructure)に関する知識キャッチアップのため、パフォーマンス効率とコスト最適化についてどのように考えているのか知りたいと思い、記事としてまとめてみました。
初学者でもサクッと読める分量で執筆しておりますので、お気軽に読んでいただければ幸いです。
目次
- パフォーマンス効率とコスト最適化の実践
- ワークロードの把握
- 要件に応じて、クラウド・サービスを評価します
- データドリブンになる
- 成長を見込みます
- 支出の理解と最適化
- まとめ
パフォーマンス効率とコスト最適化の実践
OCI公式ドキュメントでパフォーマンス効率とコスト最適化についてはパフォーマンス効率とコスト最適化の実践についてで取り上げられています。本文に沿って、私なりの解釈を入れて示していきたいと思います。
公式ドキュメント
- 本文
パフォーマンス効率とは、ワークロードがユーザーのパフォーマンス需要を満たし、必要に応じてスケーリングできるように、クラウド・リソースを効率的に使用することです。需要は時間の経過とともに変化する可能性があるため、アーキテクチャ設計の決定により、パフォーマンス効率を高めることができる新しいサービスを柔軟に組み込むことができます。
ざっくりいえば、需要分析を通じて、利用するリソースを決めることが最適解と言っています。
そのうえで、パフォーマンス効率を最適化するために必要なこととして次のことが必要だと以下の通り言及しております。
アーキテクチャおよびビジネス要件に最適なサービスを実装します。
必要に応じて新しいクラウド・サービスを利用します。
コスト効率に優れています。プラットフォーム・サービス、すなわち予算、およびコスト・トラッキング・タグを活用して、コストと支出を可視化します。
需要の増大やビジネス要件の進化時にスケーラビリティの問題を回避するスケーラブルな設計パターンを適用します。
データ主導の意思決定を可能にします。メトリックを収集して利用し、スケーラビリティと最適化を促進します。
そのために行うアクションとして以下の通り示しております。
ワークロードの把握
現在実行中のワークロードまたは計画されているワークロードのビジネス要件を理解することは、クラウド・リソースを活用して非常に効率的なパフォーマンスを実現し、コストを最適化する方法について最善の意思決定を行うのに役立ちます。オンプレミスのワークロードを類似のサイズにすると、見積りが小さすぎたり、大きすぎたりする場合があります。比較サイズ(類似)のみでなく、クラウド環境のサイズがコストを節約するために正確に調整されるように、予測サイズ設定も考慮して、デュー・デリジェンスでクラウド内のワークロードをカスタマイズおよび適切なサイズにします。可能な場合は常に、クラウドに自動スケーリングを実装して、ピーク時間帯にワークロードを処理します。Oracleクラウドでは、オンデマンドでインスタンス容量を自動的に調整して、オンプレミスとは異なりリソース使用率を最適化できます。
小難しいことが示されていますが、ざっくりいえばビジネス要件で必要なリソースをちゃんと分析して利用してくださいと言っています。（実際は、分析結果からの意思決定が難しいのですが）
要件に応じて、クラウド・サービスを評価します
既存のワークロードを移行する場合は、既存のリソースおよびコンポーネントをクラウド同等のサービスにマップできます。ただし、パフォーマンス、コスト、管理性のメリットをもたらす可能性のある他のクラウド・サービスを使用するようにアーキテクチャを更新できるかどうかは、必ず評価してください。移行を計画する際には、現在のワークロードがクラウド用に設計されているかどうかを考慮する必要があります。
場合によっては、完全に管理されたクラウド・サービスの方が高価に見えることがありますが、運用ワークロードの削減を考慮すると、この計算が変わる可能性があり、アーキテクチャの決定を行うときに考慮する必要があります。
ざっくりいえば、オンプレミス⇒クラウド移行時にワークロードもクラウド用に変えましょうねと示しています。
データドリブンになる
データとメトリックはすべてのクラウド・ワークロードの重要な部分であり、キー・パフォーマンス・インジケータの定義は、設計プロセス全体の重要な部分です。
時間の経過に伴うメトリックの収集は、次のことに役立ちます。
設計の意思決定を促進します。
ワークロードを最適化します。
スケーラビリティの問題を強調表示します。
リリース関連の問題を識別します。
エンド・ユーザーとのインタラクションに関するインサイトを提供します。
ワークロードのコスト効率を示します。
トレンドと季節性、プロジェクトの需要を表示します。
アラーム、スケーリング、修正アクションなどの自動タスクをトリガーします。
ざっくりいえば、メトリクスなどの利用可能なデータに基づいて、定期的にリソース分析を行いましょうと言っています。
成長を見込みます
クラウドにより、小規模から始めて、需要に対応したり、新しいリージョンに拡大する必要があるときに成長することができます。
ワークロードに応じて、スケーリング方法と、スケーリングをサポートするための適切なサービスとパターンを使用するかどうかを考慮する必要があります。アプリケーションの各レイヤーおよびコンポーネントを評価して、スケーリングの特性を理解します。
管理対象PaaSサービスを利用すると、リソースの自動スケーリングなどの機能が提供され、スクリプトや人的介入の必要性が最小限に抑えられます。
負荷テストを使用して、アプリケーションのスケーリング方法と、テスト中に特定のコンポーネントがホットスポットになるかどうかを決定します。
また、テナンシ・サービス制限または割当て制限ポリシーがスケーリング・シナリオで制限効果をもたらす可能性があるかどうかも考慮する必要があります。本番ワークロードとその他の非本番ワークロードの両方を含むテナンシでは、本番リソースのスケーリングを成功させるために、ポリシーと保護が実施されていることを確認する必要があります。
ざっくりいえば、ビジネス要件を実現するうえで、どのようなスケーリングを行えばいいんだっけ、成長性を考えたらそもそもスケーリングって必要なのかを見定めることだと言及しています。
支出の理解と最適化
- クラウドのコスト・モデルについて学習
リソースごとに請求と使用量の特性が異なるため、組織レベルで支出を最適化する方法を理解します。コンピューティング負荷の高いオプションやメモリー負荷の高いオプションなど、ワークロードのニーズに合ったインスタンスを選択し、リソースを効率的に実行するように調整します。データベースの問合せ、索引およびデータ構造を微調整して、より高速で効率的なパフォーマンスを実現します。小さな微調整は、応答性に大きな違いをもたらします。ネットワーク・レイアウトとルーティングを可能なかぎり効率化するように編成することで、ネットワークの遅延と帯域幅の使用量を削減し、サービスがサービス間でより迅速に移動できるようにします。
ざっくりいえば、どの部門のどのリソースがコスト増加しているか分析すると言及しています。
- コスト・ガバナンスの導入
異なるチームが同じアプローチに従うようにポリシーとプロセスを定義し、コストを統一的に評価できるようにします。Oracleのコスト管理およびガバナンス・サービスを使用して十分に利用されていないリソースを特定し、需要に基づいてスケーリングを自動化することで、クラウドの支出を最適化します。Oracle Cloud AdvisorなどのOCIのコスト管理およびガバナンス・サービスを活用して、支出の監視、説明責任の向上、クラウド効率の最適化を支援します。
ざっくりいえば、OCIサービスを用いてどのような目的でコストが発生しているか説明できるようにすることを言及しています。
- 効率の測定
データドリブンのアプローチにより、ビジネス価値と、使用されるリソースの関連コストに関してワークロードを測定できます。これにより、ビジネス目標を達成し、改善分野を特定しながら、リソースをどの程度効率的に使用しているかを理解できます。
ざっくりいえば、定期的にリソースコストの分析を行いましょうねと言っています。
- クラウド・サービスと機能の活用
自動化および管理サービスにより、ワークロードの実行にかかる全体的なコストを削減できます。これにより、環境の構築またはメンテナンス、オペレーティング・システムの更新またはデータベースのチューニングにかかるスタッフの時間が削減され、ビジネス価値は追加されません。
ざっくりいえば、自動化できるところは自動化しましょうと言っています。
- 要件が利用を促進
ビジネス要件に基づいて、リソースが必要な時期と方法、および24時間365日利用可能かどうかを定義します。これはオンプレミスの世界とは異なります。クラウドでは、必要に応じてリソースをスケーリング、停止またはプロビジョニング解除できるため、結果としてのコストに大きく影響します。
ざっくりいえば、シーンに応じてリソース増減を調整しましょうねと言っています。
まとめ
OCIを利用するうえでパフォーマンス効率とコスト最適化は重要視しなくてはいけない考えだと考えています。そのうえで、どのようにパフォーマンス効率とコスト最適化を実現するかについても、ドキュメントで言及していますが、分量が多くなるため、別建てて記事をまとめていきたいと思います。