フローを使用してワークロード設計を最適化する
この記事では、フローを使用したワークロードの対象を指定した最適化について説明します。 ワークロードのさまざまなコンポーネントには、多様な要件と重要度のレベルがあります。 ワークロードをフローに分割することで、ワークロードのさまざまな部分に優先順位を付け、ワークロードへの投資を各フローの重要性に合わせて適切に調整できます。
このワークロード最適化プロセスは反復的であり、次の 3 つの主要なステップが含まれます。(1) ワークロード内のフロー構造を定義する、(2) 技術面の要件を定義する、(3) 要件を満たすフローを設計する ("図 1 を参照")。
図 1: フローを使用してワークロードを最適化するプロセス。
フローを定義する
フロー要件を定義する前に、フローのビジネス推進要因を理解する必要があります。 フローを定義するための前提条件は、ビジネス プロセスとそれがサポートするユース ケースを特定することです。 前提条件を理解したら、フローの文書化を開始できます。
前提要件を理解する
フローは、ワークロード機能をサポートする一連のアクションです。 フローには、ユーザー フローとシステム フローという 2 つの主な種類があります。 ユーザー フローによって、ユーザー操作が決まります。 システム フローによって、ワークロード コンポーネント間の通信が決まります。 フローはビジネス プロセスとユース ケースをサポートします。 ワークロードは複数のユース ケースで構成されます。 フローを文書化する前に、フローがサポートするビジネス プロセスとユース ケースを特定する必要があります ("図 2 を参照")。
図 2: ビジネス プロセス、ユース ケース、フロー、ワークロードの関係。
ビジネス プロセスを特定する
ビジネス プロセスは、ビジネス要件を満たす一連のアクション (ステージ) です。 フローは、ユーザーまたはデータがビジネス プロセスの各ステージを完了するために実行するシーケンスを決定します。 たとえば、オンラインで製品を販売することはビジネス プロセスです。 このビジネス プロセスのステージとしては、オンラインでの製品の出品、注文の受付、製品の配送などが考えられます。
ユース ケースを特定する
ユース ケースでは、フローの機能要件を定義します。 フローの技術面の要件を制定する前に、フローがサポートするユース ケースを特定して理解する必要があります。 各ユース ケースでは、ビジネス プロセスの 1 つのステージをサポートする必要があります ("図 2 を参照")。 ユース ケースでは次の属性を定義する必要があります。
"目的": オンライン購入をできるようにするなど、タスクや目的を明確に示します。 この明確さが機能設計の指針となり、フロー設計の明確な目標を設定します。
"重要度": 定型的なものから重大なものまで、ユース ケースの重要性を評価します。 ユース ケースに割り当てられた値は、フローの優先順位付けと設計を知らせます。 価値の高いユース ケースでは、エラー処理の強化、パフォーマンス チューニング、またはユーザー エクスペリエンスに関する考慮事項が必要になる場合があります。
"コンシューマー": ユーザー (顧客、スタッフ) またはシステム コンポーネントが主要なコンシューマーであるかどうかを特定します。 この分類によって、それがユーザー フローであるかシステム フローであるかが決まり、設計に影響します。
"イベント": ユース ケースを開始および終了するトリガーまたは条件を定義します。 これらのイベントはフローの境界を定義します。
"実行": システム負荷を予測するために、ユース ケースの動作頻度と変動性を理解します。 さまざまな実行シナリオを処理するフローを設計する必要があります。
"依存関係": リスク管理のために他のユース ケースとの相互依存関係を特定します。 ユース ケースの依存関係を認識すると、他のシステム部分とスムーズに統合するフローの設計に役立ちます。 必要な入力の可用性と、出力と後続のプロセスとの互換性を確保する必要があります。
フローを文書化する
ユース ケースを使用してフローを文書化します。 フロー内で必要な各アクションの概略を説明するか、マップする必要があります。 判断基準と経路を把握します。 他のユース ケースとの相互作用を特定します。 この概略は、フローの設計と管理のブループリントとして機能します。 フローに関するビジネス情報を把握する必要もあります。 フローのドキュメントには、必ず次の詳細を含めてください。
"フローの説明": フローの概要の説明。
"ビジネス プロセス": フローがサポートするビジネス プロセス。
"プロセス所有者": ビジネス プロセスを所有する個人。
"関係者": フローの状態や変更について通知または相談する必要がある個人。
"エスカレーション パス": 問題を解決するために問い合わせる必要がある個人またはグループ。 これは一連の人物です。 個人の責任範囲は、パス上の各人物に合わせて拡大します。
"ビジネスへの影響": ビジネスに対するこのフローの重要性。
"重要度評価": フローの相対的な重要性を示す定性的なラベル。
詳細については「フローの例」を参照してください。
フロー要件を定義する
ユース ケースを利用して、フローの技術面の目標を制定します。 Well-Architected フレームワーク (WAF) の 5 つの柱に沿ったフローの測定可能な目標を定義します。 これらの柱は、技術面の目標を設定するためのフレームワークを提供します。
"信頼性の目標": 各フローの重要性を評価し、それに応じて信頼性の目標を設定します。 パフォーマンスのしきい値を決定し、明確なサービス レベル アグリーメント (SLA) と目標 (SLO) を制定します。 重要度の高いフローには、より厳格な信頼性の目標が必要です。
"セキュリティ ターゲット": データの機密性とユーザー アクティビティに基づいて、各フローのセキュリティ ニーズを分析します。 規制基準への準拠を確保しながら、これらのニーズを満たすセキュリティ対策を実装し、継続的に更新します。
"コスト目標": 効果的なリソース割り当てのための各フローの需要を理解します。 コストとパフォーマンスのバランスを取るように目標を設定します。 リソースの使用がビジネスの優先事項と一致していることを確認します。
"運用目標": 効果的な監視とトラブルシューティングのためのメトリックを定義します。 目標は、効率的なリソースの使用と組織のゴールとの整合性を確保する必要があります。
"パフォーマンス目標": 各フローの初期要件に基づいてパフォーマンス目標を設定します。 必須のフローに十分なリソースが割り当てられていることを確認し、変化する需要に対応してユーザー エクスペリエンスを向上させるために目標を継続的に調整します。
フローを設計する
技術面の目標を満たすようにフローを設計します。 適切な結果を得るには、フロー設計のベスト プラクティスをよく理解しておく必要があります。 フローを構築してテストします。 制定した技術面の目標を満たすまで設計を繰り返します。
フロー設計のベスト プラクティスに従う
フローを設計するときは、フロー設計のベスト プラクティスに従ってください。 適切に設計されたフローには次の特性があります。
"スコープを持つ": 各フローの明確な開始点と終了点を識別します。 明確な境界は、ユーザーまたはシステムの操作を最適化するのに役立ちます。
"論理的": 論理的な順序の手順でフローを設計します。 最も効率的なパスを最適化し、不要な手順を削減します。
"保守可能": 更新と保守が簡単なフローを設計します。 ワークロード全体に影響を与えずに変更できるモジュール式コンポーネントを使用します。
"定義される": フローの各手順をトリガーまたはガイドする特定の条件を組み込みます。 この精度により、フローがユーザー入力、データ変更、またはシステム状態に正確に応答することが保証されます。
"信頼性": エラー処理と例外パスをフローに組み込みます。 効果的なエラー管理により、予期しない状況下でも中断が防止され、フローの整合性が維持されます。
"スケーラブル": さまざまな負荷に対応し、ユーザー ベースやデータ量の増減に適応できることが保証されます。
"セキュリティ保護": フロー内にセキュリティ対策を埋め込みます。 不正なアクセスや脅威からデータとユーザーの操作を保護します。
"効率的": 過剰なプロビジョニングを行わずにリソースの効率的な使用を計画します。 コストの最適化に留意します。
"ユーザー中心": ユーザー フローの場合、フロー設計をユーザーの期待や行動に合わせます。 直感的にして、新しいユーザーの学習曲線を短縮します。
フローの開発とテスト
技術面の目標を達成するためにフローを開発し、それをテストして要件を満たしていることを確認します。 このプロセスでは、フローが意図したとおりに動作し、タスクを効率的に処理し、技術面の目標を満たしていることを検証します。 フローを構築してテストするためのガイダンスは次のとおりです。
"テクノロジの選択": 信頼性、セキュリティ、パフォーマンスの観点から、設定された目標に適合するテクノロジを選択します。
"フローの開発": 設定された目標を念頭に置き、設計に従ってフローを構築します。
"フローのテスト": テストを実施して、フローが目標を満たしていることを確認します。 目標を達成するために必要に応じて繰り返します。
"監視": リソースの使用状況とコストを追跡する監視ツールを実装します。
設定された目標と業界標準に照らしてフローを定期的に確認します。 監視と監査からのフィードバックを利用してフローを改善します。 変化するビジネス ニーズやテクノロジの進歩に合わせ、必要に応じて目標とプロセスを調整します。
フローを最適化する
この記事で定義されているプロセスを、フローのライフサイクル全体にわたって繰り返します。 フロー設計を繰り返し行う場合、Well-Architected フレームワークを使用して、各柱の観点からフローを最適化します。
フローの例
ここでは、フローの設計に役立ついくつかのフローの例を示します。 これらの例では、信頼性の高い 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 時間前にスケジュールする必要があります。
"重要度評価": 中。