スケーラビリティ
スケーラビリティとは、サービス品質を損なうことなく、ほぼリアルタイムでビジネス需要を満たすワークロードの機能です。従来、トラフィックの予測可能な急増に対応するために追加の容量が事前に割り当てられてきましたが、トラフィックの予期しない急増が監視され、アラートが公開されて容量が増加します。
アップスケーリングおよびダウンスケーリングでは、手動操作が必要であり、維持する容量変更の量と期間の変動計算の対象となります。スパイクが頻繁に発生し、予測不可能な場合、要件を管理することがより面倒になります。
このようなタイプのシナリオは、通常、ワークロードの永続的なアップスケール容量で管理されているため、負荷に対応できますが、長期的にワークロードを実行する場合のコストは高くなります。ハードウェア容量が使用に関係なく調達されるオンプレミスとは異なり、このタイプの容量をクラウドで管理する場合、インフラストラクチャへの永続的な投資は必要なく、最新の状態に保つためにハードウェアの更新は必要ありません。
ワークロードは、CPU、メモリー、ストレージおよび入出力(I/O)の需要容量を増加させることができます。CPUおよびメモリーは、大幅に変動する主要なパラメータです。容量は、次の2つの方法でアップスケールおよびダウンスケールできます。
- 水平スケーリング:追加の負荷に対応するためにパラレル容量が追加されます。
- 垂直スケーリング:インフラストラクチャ数を変更せずに、CPUとメモリーを増減します。
ロード・バランサをバックエンド・インフラストラクチャの前に配置することで、水平スケーリングを簡単に実現できます。これにより、既存の進行中のトランザクションに影響を与えずにロードが分散されます。垂直スケーリングでは、インフラストラクチャをスケール・アップまたはスケール・ダウンする必要があります。必要な容量はパラレルにプロビジョニングされ、ワークロードは新しい容量に転送されます。アプリケーション・システムがこれらのタイプのシナリオを管理するように設計されている場合、新しい容量に転送されるワークロードは、既存のトランザクションに最小限の影響を与えない可能性があります。
アプリケーションのスケーリング時には、アプリケーション自体のワークロードだけでなく、アプリケーションを他のアプリケーションに接続する通信メカニズムも考慮することが重要です。通信メカニズムは、あらゆる分散アプリケーションの不可欠な要素であり、システムのさまざまな部分で情報を交換し、共通の目標を達成するために連携することができます。アプリケーションのワークロードが増加すると、その通信メカニズムに対する需要も増加します。通信メカニズムがスケーリングするように設計されていない場合は、ボトルネックになる可能性があり、アプリケーションの全体的なパフォーマンスが制限されます。これにより、ユーザー・エクスペリエンスの低下、レイテンシの増加、さらにはシステム障害につながる可能性があります。
柔軟に拡張するアーキテクチャ・アプリケーションを設計するには、コンピュート、メモリー、ストレージ、ネットワーク、スループットおよびスロットルの制限のすべての側面を十分に考慮する必要があります。次の情報では、高パフォーマンスでスケーラブルなシステムを設計するための一般的なシナリオについて説明します。OCIでワークロードを実行およびデプロイするための組織のニーズ、ビジネス価値、優先順位に基づいて、アプローチを決定します。
要求時スケーリング
オンデマンド・スケーリングは、クラウド・コンピューティングの機能であり、現在の需要に基づいてアプリケーションまたはサービスに割り当てられたリソースを自動的に調整できます。ワークロードに基づいて、リアルタイムで使用するサーバー、ストレージおよびその他のリソースの数を増減できます。たとえば、OCI Computeは、メトリックおよびスケジュールに基づいてインスタンス・プール内のコンピュート・インスタンスの数を調整し、構成に従って必要な容量を満たします。
スケール・インおよびスケール・アウト
スケールインとは、アプリケーションまたはサービスに割り当てられるリソースの数を減らすことを意味し、スケールアウトとは、リソースの数を増やすことを意味します。両方のタイプのスケーリングを使用して、負荷のスパイクを処理できます。たとえば、OCIバースト可能なインスタンスは、インスタンスが通常アイドル状態であるか、CPU使用率が低く使用量が不定期な急増のシナリオ向けに設計されています。バーストが終了すると、インスタンスはベースライン容量にスケールインされます。
サービスの制限および割当て
ワークロードを設計して、アプリケーションの様々なモジュール間でバランスをとり、それぞれスケーリングします。また、テナンシのサービス制限およびコンパートメント割当ても考慮してください。たとえば、Oracle Universal Creditsサブスクリプション・モデルに対して50個のロード・バランサと5000個のMBpsを作成できます(現在、将来変更される可能性があります)。一部のサービス制限は動的であり、使用状況に基づいて時間の経過とともに増やすことができます。様々な制限および目標については、OCIの価格モデルを参照してください。
高可用性
単一障害点を排除し、ワークロードを設計して、アップタイムとアクセシビリティの可能性を最大限に高めます。OCIは、ワークロードの冗長性を確保するために、高可用性機能をフォルト・ドメインおよび可用性ドメインとして提供します。
たとえば、アプリケーション・インフラストラクチャを複数のフォルト・ドメインに分散すると、ワークロードがデータ・センター内の同じ物理ハードウェア上に存在しないように、アンチアフィニティが提供されます。アベイラビリティ・ドメインは、同じリージョン内の異なるデータ・センターが相互に分離され、フォルト・トレラントであり、同時に障害が発生する可能性が低いため、信頼性のレイヤーを追加します。リージョン内のデータ・センターは、低レイテンシと高帯域幅で相互に接続されるため、レイテンシの問題が軽減されます。
ディザスタ・リカバリ
自然災害または人為的災害による致命的な障害の場合、ワークロードに偶発的な計画を立てて別のリージョンに複製することが不可欠です。このタイプのシナリオでは、リカバリ・プロセスが唯一のオプションであり、リカバリのレベルは、アプリケーションの重要度、関連するリカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)に基づいて設計する必要があります。OCIは、データ耐久性、RTO、およびRPOに基づいて、複数の方法でディザスタ・リカバリ(DR)アプローチを提供しています。
たとえば、データベース・バックアップから別のリージョンでシステムを再構築し、低コストのDR実装のためにInfrastructure as a Service (IaaS)およびDevOpsを使用してインフラストラクチャをプロビジョニングできますが、データ損失と使用不可は高くなります。リアルタイムのレプリケーションとロード共有を備えたアクティブ/アクティブ・システムでは、コストは高くなりますが、データ損失とダウンタイムはほぼゼロです。
容量計画
パフォーマンス要件に基づいてワークロードの現在および将来の要求をサポートするために必要なリソースと、適切な量のリソースと自動スケーリングを割り当てるための成長予測を決定します。予測には、履歴監視メトリックを使用できます。
たとえば、データベース・ストレージのシェイプとサイズは、オンデマンドではなくリニア容量に基づいて事前にプロビジョニングする必要があります。履歴統計の使用を活用することで、アドホック・スケーリングを回避するための容量の定義に役立ちます。
パフォーマンス監視
アプリケーションのクラウド・リソースおよびアプリケーション統計のパフォーマンスを測定、追跡および分析して、パフォーマンス要件を満たし、ユーザーに最適なパフォーマンスを提供していることを確認します。パフォーマンスの監視は、アプリケーションでパフォーマンスの問題を識別し、ユーザーに影響を与える前に修正処理を実行できるようにするために重要です。OCI Application Performance Monitoringには、アプリケーションをモニターし、パフォーマンスの問題を診断する包括的な機能セットが用意されています。
たとえば、Application Performance Monitoringはパフォーマンスを詳細に可視化し、問題を迅速に診断する機能を提供します。また、コア・ビジネス・プロセスの提供にも注力できます。OCIは、オンプレミスまたはクラウドのクライアント、サードパーティ・サービス、バックエンド・コンピューティング層にわたる複数のコンポーネントおよびアプリケーション・ロジックを監視します。
パフォーマンスの原理
アプリケーションは、異なるモジュールおよびコンポーネントでスケーリングするように設計する必要があります。これを実現するには、アプリケーションをOCIのベストプラクティスを活用してダウンタイムをほぼゼロにスケールアップできるように設計することが不可欠です。
たとえば、アプリケーションがすでにシン・マイクロサービスに分割されている場合は、Oracle Kubernetes Engine (OKE)またはOCI Container Instancesで高パフォーマンス・シナリオを実現するために、簡単にデプロイおよびスケーリングできます。または、ロード・バランサ、散布図収集(プールとデタッチ)、結果キャッシュ、共有領域(情報エンリッチメント)、パイプとフィルタ、MapReduce(I/Oボトルネックのバッチ結合)、バルク同期パラレル、実行オーケストレータなど、実装に対するアプローチも考慮する必要があります。アプリケーションをネイティブに実行するために、キャッシュ、コマンド問合せ職責分離(CQRS)、腐敗防止、遮断器、イベント・ソーシング、パブリッシャ・サブスクライバ、シャーディング、ストラングラー、佐賀、スロットルなど、よく知られた設計パターンがあります。
原価対生産能力
クラウドの容量は、インフラストラクチャの追加または削除によって増減できます。すでにプロビジョニングされている容量を使用して、総ランニング・コストを削減することが重要です。ビジネス上重要なアプリケーションに、SLA違反を回避するために事前に容量をプロビジョニングする例外があるシナリオもありますが、これは正当です。パフォーマンスのニーズはコストの増加に比例するため、キャパシティを決定する前に、ビジネス・ニーズと優先順位に基づいて意思決定を行います。
効率性
スケーラビリティのためにクラウド・アプリケーションを設計する一面は、負荷やトラフィックの増加をコスト効率の高い方法で処理することです。アプリケーションは、リソースの使用とコストの効率を最大化するために設計および実装する必要があります。コスト最適化とパフォーマンス強化を考慮しながら、リソースの使用を監視し、自動スケーリングのために可能なかぎり自動化する必要があります。OCIは、ほとんどのサービスで構成された自動スケーリング機能を提供します。一部のクラウド・サービスは、サードパーティ・システムで自動化できます。
トレードオフ
トレードオフは、クラウド・アプリケーションとスケーラビリティにとって重要な考慮事項です。これには、アプリケーションのどの側面を優先してスケーラビリティを実現するかについての意思決定が含まれます。アプリケーションの成長と複雑化に伴い、アプリケーションのすべての側面を同時に最適化することがますます困難になります。そのため、最適なスケーラビリティを実現するにはトレードオフを行う必要があります。
考慮する必要がある一般的なトレードオフは、次のとおりです。
- パフォーマンス対コスト
- 柔軟性と複雑性
- 自己回復性とコスト
- スケーラビリティとセキュリティの比較
- 市場投入までの期間とスケーラビリティ
サーバーレスおよびコンテナの使用
サーバーレスとコンテナを使用することで、OCIのスケーラビリティを大幅に向上させることができます。これにより、必要に応じて簡単にスケール・アップまたはスケール・ダウンできる、より小さく効率的なコンポーネントにアプリケーションを分割できます。OCIでは、コンテナ・デプロイメント用にOCI Container Engine for Kubernetes (OKE)から選択して、マイクロサービスを個別にスケーリングできます。また、OCI FunctionsとOCI Container Instancesを検討して、サーバーレス・プラットフォーム・エラスティック・アーキテクチャを活用し、スケーラビリティの高いサービスを利用してワークロードをデプロイします。
データベースに関する考慮事項
データは、あらゆるアプリケーションの最も重要な部分です。システム全体は、整合性と情報に依存します。アプリケーションおよびビジネス・ニーズに合せて適切なデータベース・タイプを考慮することが重要です。
リレーショナル・データベース管理システム(RDBMS)に情報が保持されていた時代がありました。クラウドでは、様々なデータベース・オプションおよびプロバイダから選択できるようになりました。現在、データベースは独自のビジネス・ニーズに対応しており、データを処理するためにマイクロ・サイズから非常に大きな容量まで多岐にわたっています。
たとえば、Oracle Autonomous Databaseはトランザクション・データに最適ですが、MySQLは分析と機械学習に適しています。また、Oracle NoSQLデータベースは単純なデータに適していますが、単純な問合せに対する予測可能な1桁ミリ秒のレイテンシ・レスポンスを提供します。Exadataインフラストラクチャを検討して、よりセキュアで高パフォーマンスおよび分離のニーズを満たすことができます。
ストレージに関する考慮事項
データには多くの形式、サイズ、アクセス頻度がありますが、常にストレージ用の領域が必要です。オブジェクト・ストア、ブロック・ストアおよびファイル・ストアからデータを格納するオプションがありますが、それぞれに特定の目的があります。OCI Object Storageは、あらゆるタイプのコンテンツが標準、頻度の低い、アーカイブ・ストレージとして格納されるように構築されています。OCI File Storageは、ネットワーク・ストレージまたはNFSとしてマウントできる従来のファイル・システムを提供するために構築されています。OCIブロック・ボリュームは、インスタンスへのアタッチメントを目的としており、ブート・ボリュームおよびブロック・ボリュームとして使用できます。
パフォーマンス・ベースライン
このアプローチは、予想される負荷に対して維持するために、クラウドで実行するアプリケーションのベースライン・レベルのパフォーマンスを決定するために使用されます。参照パフォーマンス・ポイントを確立します。このポイントは、目的のパフォーマンス・レベルに合せてスケーリングする際に必要となる変更の将来の参照ポイントに使用されます。
ロードおよびストレス・テスト
負荷テストでは、ほぼリアルなユーザー負荷をシミュレートして、トラフィック増加に対するアプリケーション応答のパフォーマンスを測定します。これにより、パフォーマンスやクラッシュを悪化させずに、予想されるユーザーの負荷をシステムが処理できるかどうかがチェックされます。また、アプリケーションの可変負荷に対するシステムのスケーラビリティも検証します。これにより、レスポンス動作によってボトルネックが特定され、システム構成および容量計画の最適化に役立ちます。
ストレス・テストは、予想されるユーザー負荷を超えており、トラフィックや異常な負荷の急増を処理するアプリケーションの能力を検証します。また、システムを故障させずに異常で予期しない負荷を処理できるか、またはパフォーマンスを大幅に低下させるかも検証されます。これにより、システム・アーキテクチャまたは容量の弱点を識別するためのシステム制限がプッシュされるため、システムのスケーラビリティと回復性が最適化されます。
ボトルネックの識別
クラウド・アプリケーションでは、アプリケーションのスケーラビリティとパフォーマンスを確保してボトルネックを特定し、カスケード・パフォーマンスの低下に対処することが重要です。データまたは処理のフローが制限または減速され、パフォーマンスが低下し、システムが目的の容量に対して失敗する可能性があるシステム内のポイントを特定します。ネットワーク、ストレージ、処理、データベース・アクセスなど、様々な領域でボトルネックが発生する可能性があります。
データ主導型のアプローチ
モニタリング・ツールとデータ分析を使用して、システムのパフォーマンス、使用パターン、ユーザーの行動に関するデータを収集および分析し、論理的なアプローチとデータ・インサイトを実装して、システムのパフォーマンス、容量、スケーラビリティを最適化します。これにより、ユーザー・エクスペリエンスが向上し、ビジネス価値が高まります。データ主導型のアプローチを実装するための重要なステップは次のとおりです。
- データの収集と分析
- パターンと傾向の特定
- インサイトに基づいてシステム容量を最適化します。
- システムパフォーマンスを継続的に監視および調整します。
状態の監視
クラウド・アプリケーションのアプリケーション・ヘルスの監視は、必要なスケーラビリティとパフォーマンスを確保するために重要です。健全なアプリケーションは効率的に動作し、ユーザーの要求を満たします。異常なアプリケーションでは、レスポンス時間の遅い、エラー率の高い、クラッシュなどの問題が発生します。アプリケーションの健全性を監視および処理すると、問題の早期検出、パフォーマンスの最適化、ユーザー・エクスペリエンスの改善、およびコストの削減が可能になります。OCI Monitoringは、メトリックおよびアラーム機能を使用してクラウド・リソースをアクティブおよびパッシブに監視し、構成を収集して処理します。
パフォーマンス問題のトラブルシューティング
パフォーマンスの問題には、クラウド環境でトラブルシューティングを行うための様々なアプローチが必要です。クラウド内のアクセス・レベルは、ローカル・システムやオンプレミス・インフラストラクチャとは異なる場合があります。クラウドでのパフォーマンス問題のトラブルシューティングに役立つステップは次のとおりです。
- 問題を定義します。
- データを収集します。
- データの分析
- 問題の原因を特定します。
- テストと分離
- 問題に対処します。
- 監視と検証
各OCIサービスで提供される一般的なトラブルシューティング・ステップを確認することを検討してください。
サービス制限の識別
個々のクラウド・サービスの制限を考慮して、システムを非常にスケーラブルにし、最大容量を達成することが重要です。パフォーマンスの限界を知ることによって、制限内で動作するようにシステムを設計し、パフォーマンスのボトルネックやサービスの中断を回避できます。たとえば、ベア・メタルまたは仮想マシンを持つOCIコンピュート・インスタンスには、常に既知の制限と問題を考慮する必要があります。OCIロード・バランサを使用して、ロード・バランサの背後に追加の容量をデプロイすることで、パフォーマンスを向上できます。
独立したサービスSLA
高パフォーマンスでスケーラブルなシステムを設計するには、各クラウド・サービスSLAを十分に考慮して、災害時でもダウンタイムを短縮する必要があります。クラウド内の各サービスには、SLAとサービス・レベル目標値(SLO)が明確に定義されています。SLA時間が最も短い個々のサービスまたはサービスの可用性を満たす、または満たすには、システムの冗長性を考慮する必要がある場合があります。OCIは、お客様の設計およびアーキテクチャで考慮するPaaSおよびSaaSパブリック・クラウド・サービスのサービス・レベル目標を定義しています。
リリース・ノート
OCIは、新しい機能、パッチでサービスを常に更新しています。最新の変更を把握しておくと、アプリケーションの改善や新機能の実装に役立ちます。更新には、バグ修正とセキュリティ更新、サービスの中断とダウンタイム、価格設定とサービス計画の変更、コンプライアンスと規制の変更も含まれます。OCIリリース・ノートには、クラウド・サービスがアナウンスや変更に関する最新情報を入手するための統合ビューが用意されています。
原価分析と生産能力
スケーラビリティのために、サイズと形状の要件を考慮し、キャップを追加することが重要です。また、コストを正当化する理由なく高価なサービスを選択するのではなく、ニーズに合ったクラウド・サービスを検討することも重要です。不要なサービスを使用し、システムにレイヤーを追加してコストとレイテンシを削減することは避けてください。クラウド・サービスのコスト、機能および可用性の徹底的な分析は、非常にコスト効率の高いシステムを設計するために重要です。