プロバイダ固有の境界のリファクタ

AWS固有の統合コードを置き換えながら、ビジネス・ロジックを保持します。

プロバイダ固有の境界をリファクタするには、次のステップに従います。

  1. プロバイダに依存しないモジュールにビジネス・ロジックを抽出します。比較テスト中に取得されたソース・イベントをリプレイするためのAWSイベント・パーサーのみを追加します。
  2. ターゲット起動パターンのOCIアダプタ(リクエスト/レスポンス、CloudEvent、キュー・メッセージ、ストリーム・レコード、オブジェクト・イベント、通知または統合リクエスト)を作成します。
  3. 直接AWS SDKコールをインタフェースに置き換え、それらのインタフェースの背後にあるOCIサービス・コールを実装します。構成、シークレット・アクセス、ロギング、メトリックおよび再試行処理についても同じ操作を行います。
  4. 取得されたラムダ・イベントをリプレイし、ステータス・コード、ヘッダー、レスポンス本文、オブジェクト・メタデータ、ダウンストリーム書込み、副作用、エラー・メッセージおよび冪等性の動作を比較します。

イベント解析、SDKコール、IAM仮定、ロギング、パッケージ化および再試行処理から分離するビジネス・ロジックを探します。

考慮事項: プロバイダ統合と同時にビジネス・ロジックを書き換えることは避けてください。両方を変更すると、等価テストが難しくなります。

OCIが提供する内容の理解

標準のOCI構成を使用する移行ステップと、カスタム・コードを必要とする移行ステップを特定します。

Oracle Cloud Infrastructureは、ファンクションの実行、API管理、イベント、キュー、スケジューリング、アイデンティティ、ネットワーキング、可観測性およびデプロイメントのためのサービスを提供します。ただし、移行には、次のようなワークロード固有の変更が必要になる場合があります。

  • AWSイベント・ペイロードをアプリケーションが必要とする入力に変換しています
  • AWS SDKコールのOCI SDKコールへの置換
  • トリガー、再試行、順序付けおよび失敗動作の再作成
  • IAM権限およびネットワーク・アクセスの翻訳
  • CI/CDパイプラインおよび操作手順の更新

実装前に、標準OCI構成を使用するステップと、カスタム・コードを必要とするステップを特定します。より広い移行を見積もる前に、代表的なワークロードを使用してその区別を検証します。

OCI関数のパッケージ化とデプロイ

移行されたファンクションをコンテナ・イメージとして構築し、OCIファンクションにデプロイします。

ファンクションをパッケージ化およびデプロイするには、次のステップに従います。

  1. ファンクション・プロジェクトおよびfunc.yamlを作成または更新します。デフォルトではなく、測定されたソース動作からメモリーおよびタイムアウトを設定します。
  2. 以前のラムダ・レイヤーの内容、ネイティブの依存関係、ランタイムの依存関係、証明書およびシステム・パッケージを、必要に応じてイメージまたは共有ベース・イメージに移動します。
  3. コンテナ・イメージ内のイメージ・サイズ、依存性バージョン、ネイティブ・ライブラリ互換性、起動動作、初期化作業およびランタイム動作を追跡します。
  4. 本番トリガーを接続する前に、代表的な成功ペイロードおよび失敗ペイロードを使用してファンクションを構築、プッシュ、デプロイおよび起動します。

イメージのビルド、プッシュ、デプロイ、正常に起動され、シークレットを漏らさずに予想される出力がログに記録されていることを確認します。

考慮事項: 依存関係パッケージは、特にレイヤー、ネイティブ・ライブラリ、拡張機能および埋込みSDKバージョンでは、非表示のラムダの仮定が表示されることがよくあります。

繰返し可能な配信パターンの使用

本番移行では、バージョン管理された配信プロセスを使用する必要があります。

繰返し可能な配信パターンを使用するには、次のステップに従います。

  1. ファンクション・コード、構成、テストおよびインフラストラクチャ定義をまとめて格納します。
  2. バージョニングされたファンクション・アーティファクトをビルドおよびテストします。
  3. アーティファクトとその依存関係をスキャンします。
  4. 同じテスト済アーティファクトを環境間でプロモートします。
  5. Infrastructure as Codeを使用してOCIリソースをプロビジョニングまたは更新します。
  6. デプロイメント後に煙および統合テストを実行します。
  7. ロールバックのために、以前の本番アーティファクトおよび構成を保持します。

実用的な場合は、既存のCI/CDプラットフォームを使用します。OCI Functionsアーキテクチャに必要でないかぎり、ツールの変更は必要ありません。

トリガーと統合の移行

OCIで必要な起動動作を再作成します。

トリガーと統合を移行するには、次のステップに従います。

  1. HTTPワークロードの場合は、認証、メソッド、パス、ヘッダー、問合せ文字列、本体スキーマ、ステータス・コード、エラー本体、ペイロード・サイズ、タイムアウト、レイテンシおよび呼出し側の再試行動作を比較します。
  2. オブジェクト・イベントの場合、イベント・スキーマ、オブジェクト・メタデータ、ネームスペース、バケットと接頭辞のフィルタリング、作成/更新/削除動作、再試行動作、重複イベント、冪等性および入力パスと出力パス間のループ防止を比較します。
  3. キューおよびストリームについては、バッチ・サイズ、順序付け、部分的な障害、可視性または再試行動作、DLQまたは障害の宛先、ポイズン・メッセージ、バックプレッシャー、重複、スループットおよびリプレイに対する明示的な処理を設計します。
  4. スケジュール、通知、ログおよび統合フローの場合は、起動タイプ、レイテンシ、再試行回数、失敗ルーティング、ファンアウト動作、フィルタリングおよび可観測性を検証します。

各トリガーにドキュメント化されたOCIターゲット・パターンがあり、通常、失敗、再試行および重複配信シナリオのテストに合格することを検証します。

考慮事項: AWSイベント・ソース・マッピングにOCIの直接置換があると想定しないでください。AWSコントロール名ではなく、必要な動作を保持します。

一般的なラムダ・トリガー・パターン

次のマッピングは、OCI関数の移行の開始パターンです。

実装前に必要な動作を検証します。

AWSパターン OCI関数の開始パターン 検証するアイテム
ラムダへのAPIゲートウェイ OCI APIゲートウェイからOCIファンクション ルート、メソッド、認証、リクエストおよびレスポンスの形式、ペイロード制限、タイムアウト、ステータス・コードおよび同期エラー動作
EventBridgeからラムダへ OCIサービス・イベントのOCIイベントからOCI関数へ。適用可能なOCIイベント・ルーティング・サービスを使用して、より広範なルーティング要件に対応 イベント・カバレッジ、フィルタ、スキーマ、配信動作、再試行およびリプレイの要件
SQSからLambda OCI Connector HubからOCI FunctionsまでのOracle Cloud Infrastructure Queue バッチ・サイズ、表示タイムアウト、少なくとも1回の配信、オーダー、重複処理、ポイズン・メッセージおよび障害リカバリ
ラムダへのS3イベント OCIイベントからOCIファンクションへのOCIオブジェクト・ストレージ・イベント イベント・スキーマ、フィルタ、重複配信、オブジェクト権限、再試行動作およびダウンストリームの副作用
ラムダへのスケジュールされたイベント OCIリソース・スケジューラからOCI関数へ スケジュール式、タイム・ゾーン、入力ペイロード、タイムアウト、重複する実行、成功または失敗の宛先

AWSとOCIサービスの動作が同一であるとは想定しないでください。実装前に各ワークロードで必要な動作を検証します。

トリガーおよび失敗動作の保持

移行されたすべてのトリガーに必要な動作を文書化し、テストします。

トリガーおよび失敗の動作を保持するには、次のステップに従います。

  1. 移行されたすべてのトリガーについて、次の点をドキュメント化してテストします。
    • 配信が同期か非同期か
    • 所有者、再試行間隔および最大試行の再試行
    • 配信保証および重複イベントの可能性
    • オーダー要件
    • 冪等性の動作
    • バッチおよび部分障害の動作
    • 表示タイムアウトまたは確認応答の動作
    • ポイズンのメッセージ処理
    • 障害またはデッドレターの宛先
    • リプレイおよびリカバリ手順
  2. 同様のAWSおよびOCIサービスに同じ配信または障害動作があるとは想定しないでください。
  3. 重複配信が可能な場合は、繰り返し行われるイベントを安全に処理する機能を設計します。

デタッチされたOCI関数の呼出しでは、成功レコードと失敗レコードをOCIキュー、OCIストリーミングまたはOCI通知の宛先に送信できます。この動作は、切り離された呼び出しに固有であり、すべてのAWSデッドレターキューパターンのユニバーサル置換として記述すべきではありません。

IAM、シークレットおよびネットワーキングの構成

実行時の動作を、最小権限のOCIアクセスおよび承認されたネットワーク到達可能性に変換します。

OCI Identity and Access Management (IAM)、シークレットおよびネットワーキングを構成するには、次のステップに従います:

  1. 各ソース・アクションをOCIアクション、リソースおよびコンパートメントにマップします。ワークロードで実際に必要とされ、レビュー担当者が承認しないかぎり、広範なポリシーは避けてください。
  2. OCIリソースへのランタイム・アクセスには、動的グループおよびリソース・プリンシパルを使用します。許可パスと拒否パスの両方をテストします(間違ったコンパートメント、間違ったバケット、間違ったシークレット、ポリシー・ケースの欠落など)。
  3. OCI Vaultまたは承認されたパターンにシークレットを移動します。ソース・コード、イメージ、ログ、環境ダンプ、CI出力、スタック・トレースまたはエラー・メッセージにシークレット値が表示されないことを確認します。
  4. ルート・ルール、セキュリティ・ルール、サービス・ゲートウェイまたはNAT動作、プライベート・エンドポイント、DNS、TLS信頼、外部許可リストおよびダウンストリーム接続制限を検証します。

許可されたサービス・コールが成功し、拒否されたパスが安全に失敗し、許可されていないパスを公開せずに必要なネットワーク・パスに到達可能であることを検証します。

考慮事項: IAM変換は、AWSポリシー名や広範な管理ポリシーではなく、監視されたランタイム動作から開始する必要があります。

可観測性と操作の再作成

本番所有者が障害を検出、診断およびリカバリできることを確認します。

可観測性および操作を再作成するには、次のステップに従います。

  1. 相関ID、リクエストID、トリガーID、オブジェクトまたはメッセージ識別子、ステータス、期間、再試行回数、サニタイズ済エラー詳細およびダウンストリーム依存性結果を含むログを出力します。
  2. 呼出し数、期間、エラー率、タイムアウト数、スロットルまたは容量の症状、DLQまたは障害数、キュー経過時間またはバックログ、デタッチされた配信結果およびダウンストリーム障害のメトリックおよびアラームを確認します。
  3. ヘルス、レイテンシ、エラー、容量、トリガー・バックログおよび依存性ステータスのダッシュボードまたは承認済ビューを作成します。
  4. 起動テスト、ログ問合せ、アラーム・レスポンス、エスカレーション・コンタクト、ロールバック・トリガー、ロールバック・ステップおよび予想されるリカバリ時間を使用して、ランブックを更新します。

トラフィックが移動する前に、本番オペレータが移行された機能を監視およびトラブルシューティングできることを確認します。

考慮事項: 機能のみが機能する場合、移行は本番環境に対応していません。オペレータは、失敗したトリガー、シークレット、ネットワーク・パスまたはダウンストリーム依存性を検出してリカバリできる必要があります。