フローを使用してワークロード設計を最適化する

この記事では、フローを使用したワークロードのターゲット最適化について説明します。 ワークロードのさまざまなコンポーネントには、要件と重要度のレベルが異なります。 ワークロードをフローにセグメント化することで、ワークロードのさまざまな部分に優先順位を付け、各フローの重要性に合わせてワークロードの投資をより適切に調整できます。

このワークロード最適化プロセスは反復的であり、3 つの主要な手順が含まれます。(1) ワークロード内のフロー構造の定義、(2) 技術的要件の定義、(3) 要件を満たすようにフローを設計する (図 1 を参照)。

図 1: フローを使用してワークロードを最適化するプロセス。

フローを定義する

フロー要件を定義する前に、フローのビジネス ドライバーを理解する必要があります。 フローを定義するための前提条件は、ビジネス プロセスとそのサポートされるユース ケースを識別することです。 前提条件を理解したら、フローの文書化を開始できます。

前提条件を理解する

フローは、ワークロード機能をサポートする一連のアクションです。 フローには、ユーザー フローとシステム フローの 2 種類があります。 ユーザー フローによって、ユーザーの操作が決まります。 システム フローは、ワークロード コンポーネント間の通信を決定します。 フローは、ビジネス プロセスとユース ケースをサポートします。 ワークロードは、複数のユース ケースで構成されます。 フローを文書化する前に、フローがサポートするビジネス プロセスとユース ケースを特定する必要があります (図 2 を参照)。

図 2: ビジネス プロセス、ユース ケース、フロー、ワークロードの関係。

ビジネス プロセスを特定する

ビジネス プロセスは、ビジネス要件を満たす一連のアクション (ステージ) です。 フローは、ビジネス プロセスの各ステージを達成するためにユーザーまたはデータが取るシーケンスを決定します。 たとえば、製品をオンラインで販売することはビジネス プロセスです。 このビジネス プロセスの段階では、製品をオンラインで一覧表示し、注文を受け取り、製品を配送する場合があります。

ユース ケースを特定する

ユース ケースでは、フローの機能要件を定義します。 フローの技術的要件を確立する前に、フローがサポートするユース ケースを特定して理解する必要があります。 各ユース ケースでは、ビジネス プロセスで 1 つのステージをサポートする必要があります (図 2 を参照)。 ユース ケースでは、次の属性を定義する必要があります。

• 目的: オンライン購入の有効化など、タスクまたは目標を明確に明確に示します。 この明確さは、機能設計をガイドし、フロー設計の明確な目標を設定します。

• 重要度: ルーチンからクリティカルまで、ユース ケースの重要性を評価します。 ユース ケースに割り当てられた値は、フローの優先順位付けと設計を通知します。 価値の高いユース ケースでは、エラー処理、パフォーマンス チューニング、またはユーザー エクスペリエンスに関する考慮事項の強化が必要になる場合があります。

• コンシューマー: ユーザー (顧客、スタッフ) またはシステム コンポーネントが主要なコンシューマーであるかどうかを特定します。 この分類は、ユーザー フローかシステム フローかを決定し、設計に影響します。

• イベント: ユース ケースを開始して終了するトリガーまたは条件を定義します。 これらのイベントは、フローの境界を定義します。

• 実行: システムの負荷を予測するためのユース ケースの運用頻度と変動性を理解します。 さまざまな実行シナリオを処理するフローを設計する必要があります。

• 依存関係: リスク管理のための他のユース ケースとの相互依存関係を特定します。 ユース ケースの依存関係を認識することで、他のシステム パーツとスムーズに統合するフローを設計できます。 必要な入力の可用性と、後続のプロセスとの出力の互換性を確保する必要があります。

フローを文書化する

ユース ケースを使用してフローを文書化します。 フローで必要な各アクションの概要を示すか、マップする必要があります。 決定基準と経路をキャプチャします。 他のユース ケースとの対話を特定する。 このアウトラインは、フローの設計と管理のブループリントとして機能します。 また、フローに関するビジネス情報をキャプチャする必要もあります。 フローのドキュメントには、次の詳細を必ず含めてください。

• フローの説明: フローの概要説明。

• ビジネス プロセス: フローがサポートするビジネス プロセス。

• プロセス所有者: ビジネス プロセスを所有する個人。

• 利害関係者: フローの状態または変更について通知または相談する必要がある個人。

• エスカレーション パス: 問題を解決するために連絡する必要がある個人またはグループ。 これは、一連のユーザーです。 個々の責任の範囲は、パス上の各人と共に拡大します。

• ビジネスへの影響: ビジネスへのこのフローの重要性。

• 重要度評価: フローの相対的な重要度を示す定性ラベル。

詳細については、「フローの 例」を参照してください。

フロー要件を定義する

ユース ケースを利用して、フローの技術的なターゲットを確立します。 Well-Architected Framework (WAF) の 5 つの柱に合わせてフローの測定可能なターゲットを定義します。 これらの柱は、技術的な目標を設定するためのフレームワークを提供します。

• 信頼性ターゲット: 各フローの重要度を評価し、それに応じて信頼性ターゲットを設定します。 パフォーマンスしきい値を決定し、明確なサービス レベル アグリーメント (SLA) と目標 (SLO) を確立します。 重要度の高いフローでは、より厳しい信頼性ターゲットが必要です。

• セキュリティターゲット: データの機密性とユーザー アクティビティに基づいて、各フローのセキュリティ ニーズを分析します。 規制基準への準拠を確保しながら、これらのニーズを満たすためにセキュリティ対策を実装し、継続的に更新します。

• コスト目標: 効果的なリソース割り当てに対する各フローの要求を理解します。 目標を設定して、コストとパフォーマンスのバランスを取る。 リソースの使用がビジネスの優先順位と一致していることを確認します。

• 運用ターゲット: 効果的な監視とトラブルシューティングのためのメトリックを定義します。 ターゲットは、効率的なリソースの使用と組織の目標との整合性を確保する必要があります。

• パフォーマンス目標: 各フローの初期要件に基づくパフォーマンス目標。 重要なフローが適切なリソースを受け取り、進化する需要に対応し、ユーザー エクスペリエンスを向上させるために継続的にターゲットを調整するようにします。

フローを設計する

技術的な目標を満たすようにフローを設計します。 適切な結果を得るには、フロー設計のベスト プラクティスについて理解しておく必要があります。 フローをビルドしてテストします。 確立した技術的なターゲットを満たすまで、設計を反復処理します。

フロー設計のベスト プラクティスに従う

フローを設計するときは、フロー設計のベスト プラクティスに従ってください。 適切に設計されたフローには、次の属性があります。

• スコープ: 各フローの個別の開始点と終了ポイントを特定します。 境界をクリアすると、ユーザーまたはシステムの対話を最適化できます。

• 論理： 論理的なステップ順序でフローを設計します。 最も効率的なパスを最適化し、不要な手順を減らします。

• 保守可能: 更新と保守が容易な設計フロー。 ワークロード全体に影響を与えずに変更できるモジュール型コンポーネントを使用します。

• 定義: フロー内の各ステップをトリガーまたはガイドする特定の条件を組み込みます。 この精度により、フローがユーザー入力、データ変更、またはシステム状態に正確に応答するようになります。

• 信頼性: エラー処理と例外パスをフローに組み込みます。 効果的なエラー管理により、中断を防ぎ、予期しない状況でのフローの整合性を維持します。

• スケーラブル: さまざまな負荷に対応し、ユーザー ベースまたはデータ ボリュームの増加または縮小に適応できることを確認します。

• セキュリティ保護: フロー内にセキュリティ対策を埋め込みます。 未承認のアクセスや脅威からデータとユーザーの操作を保護します。

• 効率的: 過剰なプロビジョニングを行わずにリソースを効率的に使用することを計画します。 コストの最適化に留意してください。

• ユーザー中心: ユーザー フローの場合は、フロー設計をユーザーの期待と動作に合わせます。 直感的に操作し、新しいユーザーの学習曲線を減らします。

フローを開発してテストする

技術的な目標を満たすためにフローを開発し、それをテストして要件を満たしていることを確認します。 このプロセスは、フローが意図したとおりに動作し、そのタスクを効率的に処理し、技術的な目標を満たしていることを検証します。 フローを構築してテストするためのガイダンスを次に示します。

• テクノロジの選択: 信頼性、セキュリティ、パフォーマンスの観点から、設定されたターゲットに合わせたテクノロジを選択します。

• フローの開発: 設定されたターゲットを念頭に置いて、設計に従ってフローを構築します。

• テスト フロー: フローがターゲットを満たしていることを確認するためのテストを実施します。 ターゲットを満たすために必要に応じて反復処理します。

• 監視: リソースの使用状況とコストを追跡するための監視ツールを実装します。

設定されたターゲットと業界標準に対してフローを定期的に確認します。 監視と監査からのフィードバックを使用して、フローを改善します。 変化するビジネス ニーズや技術の進歩に合わせて、必要に応じてターゲットとプロセスを調整します。

フローを最適化する

フローのライフサイクル全体を通して、この記事で定義されているプロセスを繰り返します。 フロー設計を反復処理するときは、Well-Architected Framework を使用して、各柱の観点からフローを最適化します。

• フローの信頼性
• フロー セキュリティ
• フロー コストの最適化
• フローオペレーショナル エクセレンス
• フローパフォーマンス効率

フローの例

フローの設計に役立つフローの例をいくつか次に示します。 この例では、 信頼性の高い Web アプリ パターン参照アーキテクチャ を基礎として使用し、各フローに必要なドキュメントを示しています。

ユーザー フロー 1: 今後のコンサートを作成する

フローの説明: コール センターの従業員は、アプリケーションを使用して今後のコンサートを作成します。

• ビジネス プロセス: このフローは 購入チケット プロセスを サポートしますが、非同期であり、重要度が低下します。

• プロセス所有者: 営業部長。

• 利害関係者: 営業部門、コンサートの計画と運用、プラットフォーム チーム、アプリケーション チーム。

• エスカレーション パス: アプリケーション チーム、プラットフォーム チーム、営業部門。

• ビジネスへの影響: このフローは、新しいコンサートを販売プラットフォームで利用できるようにし、ビジネスのメイン収益ストリームに直接影響を与える上で重要です。 コール センターの従業員がこのフローを利用できないためにコンサートを作成できない場合、収益と会社の評判の両方に悪影響を与えます。 ただし、コンサートは通常毎週事前にスケジュールされるため、このプロセスでは高可用性は不可欠ではありません。 営業部門は、このプロセスに対して 95% の可用性の要件を指定し、メンテナンスのために営業時間外のダウンタイムに同意します。

• 重要度評価: 低。

ユーザー フロー 2: コンサートを検索する

フローの説明: コール センターの従業員は、アプリケーションを使用して今後のコンサートを検索します。

• ビジネス プロセス: このフローは 購入チケット プロセスを サポートしますが、検索機能が利用できない場合は、コール センターの従業員はすべてのコンサートを一覧表示することを選択できます。

• プロセス所有者: ユーザー エクスペリエンス (UX) 部門。

• 利害関係者: 営業部門、プラットフォーム チーム、アプリケーション チーム。

• エスカレーション パス: アプリケーション チーム、プラットフォーム チーム、営業部門マネージャーのオンコール。

• ビジネスへの影響: このフローにより、コール センターの従業員はコンサートをすばやく見つけ、通常の販売プロセスの一部になります。 従業員は不在時でもコンサートを一覧表示する機能を持っているので、このフローの高可用性は重要ではありません。 コール センターの従業員のエクスペリエンスが低下し、生産性に影響を与える可能性があります。 待機時間や遅延の増加により、お客様が不満を経験する可能性があります。 営業部門は、通常の営業時間中にこのフローの 99% の可用性を要求しました。

• 重要度の評価: 中。

ユーザー フロー 3: コンサートの一覧を取得する

フローの説明: コール センターの従業員は、アプリケーションを使用してコンサートの一覧を取得します。

• ビジネス プロセス: このフローは 、購入チケット プロセスを 直接サポートします。

• プロセス所有者: プラットフォームのディレクター。

• 利害関係者: 営業部門、プラットフォーム チーム、データ チーム。

• エスカレーション パス: データ チーム、データ チームのオンコール エンジニア、プラットフォーム チームのオンコール エンジニア。

• ビジネスへの影響: このフローは、ビジネスの収益を生み出すトランザクションの重要なパスに不可欠です。 コール センターの従業員はこのフローを利用してチケット購入を処理するため、高可用性が不可欠です。 その重要性を認識するために、ビジネスでは、このフローに対して 99.9% のアップタイム (延長された営業時間を含む) が義務付けられています。

• 重要度評価: 高。

ユーザー フロー 4: チケットを購入する

フローの説明: コール センターの従業員は、アプリケーション ( 認証と承認 プロセス) を使用して、Relecloud のお客様に代わって、今後のコンサート (今後のコンサート プロセスの 一覧 ) のチケットを購入します。

• ビジネス プロセス: このフローは、アプリケーションのコア機能とフローです。

• プロセス所有者: 営業部長。

• 利害関係者: 営業部門とすべての技術チーム。

• エスカレーション パス: アプリケーション チームのオンコール エンジニア、プラットフォーム チームのオンコール エンジニア、データ チームのオンコール エンジニア、最高執行責任者。

• ビジネスへの影響: このフローの高可用性は、顧客チケットの購入を直接可能にしているため、非常に重要です。 このフローの誤動作や使用不能は、収益と会社の評判の両方に大きな影響を与える可能性があります。 ビジネスは、この重要なプロセスに対して厳しい要件を設定し、延長営業時間中でも 99.9% のアップタイムを期待しています。

• 重要度評価: 高。

ユーザー フロー 5: 認証と承認

フローの説明: コール センターの従業員は、アプリケーションに安全にサインインします。 管理者は、Relecloud のお客様に代わってチケットを購入するための適切なロールを提供します。

• ビジネス プロセス: このフローは 、購入チケット プロセスを 直接サポートします。 この機能がないと、コール センターの従業員はアプリケーションにサインインしてチケットを購入することはできません。

• プロセス所有者: プラットフォーム チーム。

• 利害関係者: プラットフォーム チーム、運用チーム、営業部門。

• エスカレーション パス: プラットフォーム チームのオンコール エンジニア、最高執行責任者。

• ビジネスへの影響: このフローが正しく機能しない場合、コール センターの従業員はチケットを購入できないため、このフローには高可用性が必要です。 このフローが利用できない場合は、収益と評判に直接影響します。 これは、業務時間の延長を含め、ビジネスで 99.9% のアップタイムを期待する重要なプロセスです。

• 重要度評価: 高。

システム フロー: テレメトリを収集する

フローの説明: 運用システムの状態の変化を理解するために、Web アプリケーションと API インスタンスは情報、エラー、警告を収集して送信します。 このデータは、運用チームが異常検出、トラブルシューティング、プロファイリングを実行するのに役立ちます。

• ビジネス プロセス: このフローはビジネス プロセスをサポートしていませんが、運用チームにとって重要なデータを提供します。

• プロセス所有者: 操作のディレクター。

• 利害関係者: 運用チーム、プラットフォーム チーム、データ チーム。

• エスカレーション パス: 運用チーム (24 時間 365 日)、データ チームのオンコール エンジニア。

• ビジネスへの影響: このフローは、ビジネスの監視と継続的な改善作業に不可欠です。 可能な限り冗長で回復性が必要です。 運用チームは、エラーが発生した後にこのフローを迅速に復元し、重要な情報と警告が見つからないのを回避する責任を負います。 フローが予想される可用性を達成できない場合は、運用環境の問題を見落とすリスクがあり、重大な結果につながる可能性があります。 このリスクを軽減するために、運用部門は 24 時間 365 日 99% のアップタイムを目指しています。 少なくとも 48 時間前までにメンテナンス関連のダウンタイムをスケジュールする必要があります。

• 重要度の評価: 中。