8月最初の週、AWS Transformは3つのローンチを出した。合わせると、まだ変換していないスキーマから、カットオーバーの1年後に見つける技術的負債まで、移行の全行程を覆う。 8月3日、WindowsモダナイゼーションエージェントにSQL ServerからAurora PostgreSQLへのオフラインスキーマ変換が加わり、継続的モダナイゼーションがGAになった。8月6日には移行ワークフローがSystems Manager経由で起動後アクションを実行できるようになった。その周りでは、Lambdaが最大3,000 Mbpsのネットワーク帯域を得、Aurora Serverlessが1秒で12 ACUまで跳ねるようになり、ロードバランサーはNSA水準のTLSポリシーを拾った。

今週のテーゼはこうだ。AWSはもうTransformをAIのラベルを貼ったリホストツールとして売っていない。かつてはパートナーのスプレッドシートだった移行の部分を埋めつつあり、それはあなたが手作業でやると想定すべきことを変える。

AWS Transform: スキーマ、カットオーバー、その後の1年

3つを移行の順に見ていこう。オフラインスキーマ変換はSQL ServerのDDLファイルを受け取るので、ソースへのライブ接続は不要だ。データベースとストアドプロシージャの複雑さを評価し、生成された計画を編集させ、テーブル、スキーマ、ストアドプロシージャ、関数を変換し、機能的等価性を検証して、結果をAurora PostgreSQLにデプロイする。ストレージオブジェクトの変換は裏でAWS DMSが担う。今のところUS East (N. Virginia)のみ。オフラインという部分は聞こえ以上に重要だ。データベース移行を始められないチームというのは、たいていDBAが変換ツールにポートを開けてくれないチームだからだ。DDLダンプのほうが話は通しやすい。

起動後アクションは「サーバーがAWSで起動した」と「サーバーが本当に我々のものになった」の間の溝を埋める。アクションをアカウントレベルで一度定義すると、Transformはそれをすべてのソースサーバーに、マルチアカウント移行ではターゲットアカウントをまたいで適用し、テスト起動やカットオーバー起動の直後にAWS Systems Manager経由で実行する。定義済みアクションでも自前のSSMドキュメントでもよい。移行インベントリファイルにもサーバー単位のレビュー用の構造が加わる。MGNを大規模に回した経験があるなら、これが取り除く障害モードを知っているはずだ。80台のウェーブが着地し、誰かが79台にCloudWatchエージェントのインストールを手で走らせる。

継続的モダナイゼーションは、その後に起きることを狙った部品だ。GitHubのorganization、GitLabのグループ、Bitbucketのワークスペースに接続し、オンデマンドまたはスケジュールで実行し、検出結果を技術的負債、セキュリティ、エージェント対応度、モダナイゼーション対応度でランク付けし、修正のある検出結果については検証済みの変更でpull requestやmerge requestを開く。分析はあなた自身のアカウントであなたの認証情報のもとで動き、Webアプリ、CLI、Kiro、あるいはエージェントプラグインから駆動できる。トレードオフはあらゆる自動PRツールが抱えるものと同じで、レビュー能力だ。チームが読めるより速くPRを開くスケジュール実行のスキャナーは、四半期のうちにノイズになる。1つのリポジトリグループと厳しいランクフィルターから始めること。

Lambdaの帯域: 3,000 Mbps、ただしVPCの外にいるなら

Lambdaのネットワーク帯域は、2 GB以上のメモリを持つ関数でメモリに応じてスケールするようになった。2 GBで625 Mbps、10 GBで3,000 Mbpsまでで、一律625 Mbpsの天井が置き換わる。追加料金なし、全商用リージョン。ローンチには2つの注意点がついてくる。第一に、オプトイン方式で、Service Quotasの「Network bandwidth per execution environment」クォータの申請が必要で、その後アカウント内のすべての非VPC関数が自動的にスケールする。第二に、こちらがより重要だが、適用されるのはVPCの外にある関数だけだ。大きなオブジェクトを動かすエンタープライズの関数の多くはVPCの中にいる。RDSインスタンスとプライベートS3エンドポイントがそこにあるからだ。重いS3からS3への変換がVPC内で動いているなら、今週はあなたにとって何も変わっていない。クォータ申請を出す前にaws lambda get-function-configuration --function-name X --query VpcConfigで確認すること。

Aurora Serverless: 1秒で12 ACU

Aurora Serverlessはスケールアップ時に1秒以内で最大12 ACUに達し、そこから256まで続け、その後も引き続きゼロまでスケールダウンする。プラットフォームバージョン3または4のクラスターではデフォルトで有効で、バージョン1と2は4へ直接アップグレードできる。自分のクラスターはdescribe-db-clustersのServerlessV2PlatformVersionフィールドで確認できる。AWSはこれをエージェント型ワークロードの文脈で語っており、それは妥当だ。エージェントのファンアウトは、かつて最初の30秒をキャパシティ待ちに費やしていたバーストそのものだ。障害モードはコストだ。以前はゆるやかに立ち上がっていたクラスターが、2 ACUで吸収できたはずのスパイクで12 ACUに達する。プラットフォームバージョンを上げる前にServerlessDatabaseCapacityのCloudWatchアラームを置くこと。最初の請求書の後ではなく。

今週のその他

通底するテーマ

TransformのローンチをLambdaとAuroraのものと並べて読むと、パターンは手作業がどこに隠れていたかの話になる。スキーマ変換は誰も承認しないファイアウォールルールの裏に隠れていた。起動後の設定はランブックに隠れていた。技術的負債はバックログに隠れていた。Lambdaの帯域の天井はクォータの裏に、Auroraの立ち上がりはすべてのスパイクの最初の30秒に隠れていた。AWSはこの週を隠れ場所の撤去に費やした。その代償は毎回同じだ。デフォルトはより攻めたものになり、プラットフォームチームはそのデフォルトのどれを本当に望むのかを、前もって決めなければならない。

次に読む

同じ週のAIとエージェント側の読み解きは、ercan.aiのフィールドノートにある。AWS、クラウド、CI/CDパイプライン、Linux、GitHub/GitLabなどのコンサルティングは、ercanermis.comからどうぞ。

参考資料