9月7日の週は、AWS Transform for .NETがクリックして進めるツールであることをやめ、パイプラインに置くステップになった週だった。 1行のCLIがGAになり、同じ変換が書き換えたコードのユニットテストを生成し始め、AWS Transformがサーバー移行向けにGovCloud (US-West)に到達した。その周りでは、Lambda Managed Instancesが90分のタイムアウトとGraviton5を得、EBS Volume Clonesが再暗号化付きでアカウント境界を越えられるようになり、42Uのシングルラック OutpostsがGAになった。

AWS Transform for .NET: CLI、テスト、GovCloud

3つのローンチ、1つの方向。9月9日、AWS Transform for .NETのモダナイゼーションがCLI経由でGAになった。1つのコマンドがAWS Transform customでAWSマネージドの変換を起動し、対話的に実行することも、既存のパイプラインにスクリプトとして組み込んで無人で動かすこともできる。変換には月50,000分の無料エージェント時間が含まれ、8リージョンで利用できる。N. Virginia、Mumbai、Tokyo、Seoul、Sydney、Canada (Central)、Frankfurt、London。

9月10日、AWS Transform for .NETがモダナイズしたコードのユニットテストを生成し始めた。標準の.NETアセスメントと並行してアプリケーションのテスト容易性を評価し、どのクラスとメソッドをカバーするか(ビジネスロジック、コントローラー)を計画し、同じジョブの一部としてテストコードを出力する。オプトインで、ジョブ開始時または変換完了後に有効化し、現時点ではAWS Toolkit for Visual Studio経由だ。

そして9月8日、AWS TransformがAWS GovCloud (US-West)に到達した。範囲が重要だ。これはサーバー移行の機能(VMware、ベアメタル、Hyper-V、データベースワークロード、いずれかのGovCloudリージョンへのレプリケーションとカットオーバー)だ。モダナイゼーション、カスタム変換、アセスメントは今のところ商用リージョンに残る。

重要なのはCLIだ。IDEの中に住むモダナイゼーションはプロジェクトで、CIで走るモダナイゼーションはプロセスだ。ブランチ上で変換を毎晩走らせ、出力を昨日のものと差分し、エージェントを通るか通らないかの他のあらゆるビルドステップと同じように扱える。8つではなく80のサービスをモダナイズするとはそういうことだ。

備えるべき障害モードはテストだ。変換後のコードから生成されたテストスイートは、変換後のコードの振る舞いを符号化する。移行後に変更するあらゆるものに対する回帰の網としては価値があるが、移行が.NET Frameworkのオリジナルの振る舞いを保ったことは証明しない。それには依然として古いスイートか、古いバイナリに対して書いた特性化テストを新しいバイナリに対して走らせる必要がある。生成されたテストは床として使い、承認印としては使わないこと。

Lambda Managed Instances: 90分とGraviton5

9月9日、LambdaがLambda Managed Instancesに90分の関数タイムアウトを追加した。非同期呼び出しとイベントソースマッピング呼び出し向けで、10年にわたりLambdaのアーキテクチャを定義してきた15分の天井の6倍だ。同期呼び出しは15分のまま。長いほうの上限はLambda durable functions内のステップにも適用される。同日、Managed InstancesがGraviton5搭載のC9g、C9gd、M9g、M9gdインスタンスを得た。AWSはGraviton4に対して最大25%のコンピュート性能向上を謳う。

Managed Instancesはすでに料金モデルを変えていた(EC2インスタンスの経済性、インスタンスあたり複数の同時リクエスト)。今回の変更がその考えを完成させる。これは関数の形をしたプログラミングモデルを持つマネージドコンピュートフリートだ。メディアのトランスコード、モンテカルロの実行、バッチ推論は、15分を越えるためだけにStep Functionsのチェーンや ECSタスクを必要としなくなる。

変わらないこと。非同期呼び出しはat-least-onceだ。部分的な失敗の後にリトライされる90分のジョブは、90分を2回支払わせ、進行しながら書き込むなら半分書かれた結果を残す。べき等キーとチェックポイントは90分ではより重要になる。軽くなるのではない。そしてManaged InstancesはEC2キャパシティとして課金されるので、長時間動くワークロードを移す前にFargateタスクやAWS Batchジョブとのコスト比較を明示的に行うこと。勝ちは運用面にあり、自動的に財務面にあるわけではない。

EBS Volume Clonesがアカウントをまたぐ、新しい鍵で

9月9日、EBS Volume ClonesがAWSアカウント間のコピーをサポートし始めた。ターゲットアカウントのKMSキーで再暗号化する。流れはこうだ。ソースボリュームをAWS RAMで共有し、ターゲットアカウントが同じアベイラビリティゾーンにコピーを作る。暗号化されていないボリュームやカスタマーマネージドキーのボリュームを含め、すべてのボリュームタイプで動く。

AWSが先頭に掲げるユースケースは正しい。隔離された開発アカウントへの本番データベースボリュームの新鮮なコピーだ。従来の方法はスナップショット、スナップショットの共有、新しい鍵でのスナップショットのコピー、ボリュームの作成の4ステップで、待ち時間が長かった。新しい方法は鍵の分離が組み込まれた1回のコピーで、ランディングゾーンの「本番の鍵は本番を離れない」というルールが実際に求めるものだ。

プラットフォームチームが書き留めるべきことが2つある。第一に、「同じアベイラビリティゾーン」は同じ物理ゾーンを意味し、ゾーン名(eu-west-1a)はアカウントごとに異なる対応をする。自動化ではAZ ID(euw1-az1)を使うこと。さもないとコピーは開発用サブネットがカバーしないゾーンに着地する。第二に、本番データを開発環境にクローンするのはデータガバナンスのイベントであって、ストレージのイベントではない。RAM共有を承認の後ろに置き、誰が何をコピーしたかを記録すること。簡単な仕組みには明示的な統制が要る。

今週のその他

通底するテーマ

今週の見出しはどれも、何かを「人がやる」から「パイプラインがやる」へ動かした。TransformはCLIから走り、自分でテストを書く。Lambdaはジョブを90分保持し、15分目のあたりでオーケストレーションを手作りする必要をなくす。EBSは本番ボリュームを正しい鍵で1回の操作で開発環境にコピーする。Systems Managerは推測させる代わりに、インスタンスが管理対象外である理由を教える。それぞれが、かつて人間のステップを必要としたプロセスからそのステップを取り除く。プラットフォームチームの仕事は、そのステップのどれが理由あってそこにあったか(本番データが本番を離れる前の承認)を見極め、ツールがもう強制してくれなくなった今、意図的にそれらを残すことだ。

次に読む

同じ週のAIとエージェント側の読み解きは、ercan.aiにある。チームがAWS、クラウドアーキテクチャ、CI/CDパイプライン、Linux、GitHubやGitLab、そしてその周りのプラットフォーム業務で実践的な支援を必要としているなら、コンサルティング側はercanermis.comにある。

参考資料