ラムダ・ワークロードのインベントリ

ソースの動作を再現および比較するのに十分な証拠を持つ移行レコードを作成します。

ラムダ・ワークロードをインベントリするには、次のステップに従います。

1. 構成、デプロイメント・パス、依存関係、レイヤー、ネイティブ・ライブラリ、環境変数、VPC設定、IAMロール、トリガー、所有者および運用連絡先を記録します。
2. ベースライン・メトリックの取得: 呼出し率、ピーク同時実行性、p95およびp99期間、最大期間、使用済メモリー、ペイロード・サイズ、エラー、タイムアウト、スロットル、再試行、DLQまたは失敗数、キュー経過時間またはバックログ、アラームしきい値およびダウンストリーム容量制限。
3. 代表的な成功イベント、不正なイベント、重複イベント、タイムアウト・ケース、権限障害、ダウンストリーム障害サンプル、および機密値がリダクションされたソース・ログの例を保存します。

検索: エビデンス・リンク、初期リスク・ノート、所有者の確認が必要なギャップを含む完全な在庫レコード。

出力: 構成エクスポートのみに依存しません。通常、ログ、メトリック、アラーム、および代表的なイベントは、構成のみでは表示されない動作を示します。

OCI関数移行の各サンプリング済関数の評価

各サンプリングされた関数の要件、必要な変更および移行の決定を記録します。

OCI関数の移行用にサンプリングされた各関数を評価するには、サンプリングされた関数ごとに次の項目を含む評価レコードを完了します:

• 関数名およびアプリケーション所有者
• ビジネス目的と重要性
• ランタイムとバージョン
• トリガーおよび受信イベント形式
• 使用されるAWSサービスおよびSDKコール
• 実行時間、メモリー、同時実行性およびペイロード・サイズ
• 再試行、順序付け、重複配信および失敗動作
• IAM権限およびネットワークの依存関係
• 現在のログ、メトリック、アラームおよびサービス・レベルの目標
• 必須のOCI関数構成およびトリガー・パターン
• 必要なコード、アダプタまたはデプロイメントの変更
• 既知のギャップと未解決のリスク

次の評価結果のいずれかを使用します。

• OCI関数の移行準備:ワークロードは、限られた変更でOCI関数に移動できます。
• 変更を伴うOCIファンクションの移行:ワークロードには、アダプタ、ターゲット・コードの変更、構成の変更または操作の変更が必要です。
• 例外レビューが必要: OCI関数は、文書化されたワークロード要件を満たしていない可能性があります。このプレイブックに記載されている例外レビューがないと、非機能アーキテクチャを続行しないでください。

アプリケーション所有者および移行所有者は、実装を開始する前にアセスメントをレビューする必要があります。

OCI関数の移行要件の評価

ワークロードのOCI関数移行アプローチを決定します。

OCIファンクションの移行要件を評価するには、次のステップに従います:

1. ワークロードのトリガー、ランタイム、依存関係、実行期間、メモリー、同時実行性、ペイロード、IAM、ネットワーキングおよび運用要件を確認して、OCI Functions移行アプローチを決定します。
2. 移植可能なビジネス・ロジックを、AWS固有のイベント解析、SDKコール、IAM仮定、ロギングおよび再試行処理から分離します。

   これにより、実装が開始される前に、必要な移行変更が表示されます。

3. 次のOCI関数移行パターンを開始点として使用します。

   ワークロード・パターン	OCI関数の移行パターン	検証
   ステートレスでイベントドリブンな短時間のワークロード	OCI関数	ペイロード、メモリー、タイムアウト、同時実行性、依存関係、および必要なダウンストリーム・アクセス
   HTTP APIワークロード	OCI APIゲートウェイとOCIファンクション	認証、メソッド、ルート、ヘッダー、ペイロード・サイズ、エラー・レスポンス、レイテンシおよびタイムアウト
   オブジェクト、通知、キュー、ストリームまたはログ・イベント・プロセッサ	適用可能なOCIイベント、Oracle Cloud Infrastructure Queue、OCI通知、OCIストリーミングまたはOCI Connector Hubサービスを使用したOCI関数	イベント形式、配信動作、再試行、順序付け、重複処理、障害宛先およびバックプレッシャー

OCI関数は、ワークロードの機能、パフォーマンス、セキュリティおよび運用要件を満たしている場合のラムダ移行イニシアチブのデフォルトのターゲットです。

ターゲットOCIアーキテクチャの設計

呼出し、アイデンティティ、シークレット、ネットワーク、依存関係、可観測性およびカットオーバー・パターンを定義します。

ターゲットOCIアーキテクチャを設計するには、次のステップに従います。

1. 起動パスおよびドキュメントに必要な認証、ペイロード・シェイプ、ヘッダーまたはメタデータ、レイテンシ、再試行、順序付け、バッチ動作、重複配信、フィルタリングおよび失敗宛先を選択します。
2. OCI Functionsアプリケーション、コンパートメント、イメージ・リポジトリ、VCN、サブネット、ルート表、セキュリティ・ルール、サービス・ゲートウェイまたはNATゲートウェイ、プライベート・アクセス、エグレス要件およびダウンストリーム・エンドポイントを定義します。
3. OCI Object Storage、OCI Queue、OCI Streaming、OCI Vault、データベース、サードパーティAPIなど、実行時に関数コールを行うすべてのOCIサービスまたは外部エンドポイントを特定します。
4. ログ・フィールド、相関ID、呼出し数、期間、エラー、タイムアウト、容量の症状、ダウンストリーム障害、ダッシュボード・ビュー、アラーム、ランブック・ステップなどの操作シグナルを定義します。

コンポーネント・リスト、統合パス、セキュリティ設計、運用設計および図の再描画ガイダンスを含むターゲット・アーキテクチャのサマリーを探します。

考慮事項: アーキテクチャの設計は、通常のフロー、再試行フロー、障害フロー、拒否アクセス・フローおよびロールバック・フローが記述されている場合にのみ完了します。

設計上の考慮事項とターゲットの選択

これらの考慮事項は、設計レビュー時に使用します。

これらは意図的にアクション指向であるため、レビュー担当者は準備に関する一般的な記述を受け入れるのではなく、証拠を求めることができます。

• ターゲット適合: OCI関数は、ターゲット制限および呼出しモデルに適合するステートレスでイベント駆動型の短時間実行コンテナ化可能な作業に使用します。長時間実行、ステートフル、デーモンのようなオーケストレーション重負荷、ワーカーのような、またはAWS-service-coupledワークロードに別のターゲットを使用します。
• ペイロードおよびタイムアウト: 実際のリクエスト・サイズとレスポンス・サイズ、最大期間、タイムアウト数およびコール元レスポンス・セマンティクスを記録します。ファンクション・ペイロードではなく、OCIオブジェクト・ストレージ、OCIキュー、OCIストリーミングまたは別のストアを介して、参照によって大きなデータを渡します。
• 依存性: ZIPおよびラムダ・レイヤーの仮定をイメージまたは共有ベース・イメージの依存性に変換します。ネイティブ・ライブラリ、イメージ・サイズ、依存性バージョン、起動動作、埋込みSDKの仮定およびランタイム動作をテストします。
• 同時実行性とスケーリング: AWSが予約またはプロビジョニングされた同時実行性が使用された理由(予約容量、トラフィック上限、コールド・スタート削減、イベント・ソース・スロットル、ダウンストリーム保護)をインベントリします。キャパシティ・プランニング、プロビジョニングされた同時実行性により、コントロールのトリガー、バックプレッシャーおよびダウンストリームの制限により、OCIの動作を設計します。
• トリガー: イベント・シェイプ、再試行、順序付け、バッチ動作、重複配信、フィルタリング、失敗宛先および冪等性を検証します。トリガー動作は通常、最もリスクの高い移行領域です。
• 操作: ログ、メトリック、アラーム、ダッシュボード、トレース、ランブック、ロールバック・トリガーおよびロールバック所有者を、カットオーバー後のクリーンアップではなく移行の成果物として扱います。

ターゲット選択ガイド

ワークロード特性	推奨OCIターゲット	理由
ステートレス、イベントドリブン、短時間、コンテナ化可能な機能	OCI関数	ペイロード、タイムアウト、メモリー、トリガー、依存性、ネットワークおよび同時実行性の制約が満たされた場合に最も適合します。
単純なリクエスト/レスポンス動作を持つHTTP API関数	OCI APIゲートウェイとOCIファンクション	認証、ヘッダー、ペイロード・サイズ、タイムアウト、待機時間、ステータス・コードおよびレスポンス・セマンティクスが検証される場合に適しています。
オブジェクト、通知、キュー、ストリームまたはログ・イベント・プロセッサ	OCIイベント、OCI通知、OCIコネクタ・ハブ、コネクタ・ハブを介したOCIストリーミング、または再設計されたメッセージング・フローを使用したOCI関数	適合の可能性はありますが、配信、再試行、順序付け、バッチ、重複、ポイズン・メッセージおよび失敗動作を再設計してテストする必要があります。
長時間実行されるジョブまたはワーカーのようなプロセス	OCI Container Instances、OKE、OCI Computeまたは分解ワークフロー	コンテナまたはサービスベースのデプロイメント・パスを保持しながら、ファンクションの呼出しおよび実行時制約を回避します。
統合重視のオーケストレーション	Oracle Integration、ワークフロー・サービス、または再設計	ワークロードがシステムを調整したり、外部の状態を待機したり、わずかなコンピュート・ユニットを実行するのではなく、補正ステップを管理する場合に、より適しています。
ステートフル・プロセス、ローカルの永続状態またはデーモン	OCI Compute、OKE、または再設計	OCI関数は、永続的なローカル状態またはデーモン実行モデルではありません。

OCIリソースとデプロイメント・アクセスの準備

ビルド、デプロイおよび喫煙テストに必要な最小ターゲット環境を準備します。

OCIリソースおよびデプロイメント・アクセスを準備するには、次のステップに従います。

1. コンパートメント、OCI Functionsアプリケーション、VCNサブネット、OCI Container Registryリポジトリ、OCI Vaultシークレットの場所、リソースのロギングおよびアラームのモニタリングを作成または識別します。
2. イメージの構築、イメージのプッシュ、ファンクションのデプロイ、煙テストの起動およびログの読取りを行うための開発者およびCI/CDアクセスを構成します。
3. ランタイム・アクセス用の動的グループ・ルールおよびポリシー・ステートメントを作成します。特にバケット、ストリーム、キュー、OCI Vaultシークレットおよびデータベースの場合、可能な場合はコンパートメントおよびリソース別にスコープします。
4. Smoke-testイメージ・プッシュ、ファンクションのデプロイ、直接呼出し、ログの発行、シークレット読取り、シークレット読取りの拒否、および代表的なダウンストリーム・サービス・コールの1つ。

アクセス・パスが文書化され、煙テストに合格した、準備ができたターゲット環境を探します。

考慮事項: プロセスで異なる権限が必要な場合、デプロイメント・アイデンティティとランタイム・アイデンティティが分離されていることを確認します。