はじめに
こんにちは、YSHPブロックの岩切です。普段はシステムリプレイスを担当しています。YSHPブロックでは2025年から、ZOZOTOWN Yahoo!店に関わる連携基盤を段階的に刷新しています。
本記事では、移行初期の意思決定（言語・実行基盤・クラウド移行方針）にフォーカスし、判断材料・比較観点・想定される課題とその回避策を整理して紹介します。
目次
背景・課題
ZOZOTOWN Yahoo!店との商品・注文連携は、長年にわたりWindows Server上のVBScriptバッチで運用してきました。堅実に稼働してきた一方で、以下の課題が顕在化していました。
言語サポートの終了（EOL）
VBScriptは将来的に廃止予定であり、早めの移行計画が現実的だと判断しました。サービス成長・保守性・人材確保の観点からも、将来を見越した再設計が必要でした。
規模拡大への追随
GMVの拡大に伴い、バッチ処理量や同時実行数の増加に対応できる仕組みが必要になりました。特に運用の容易性の向上が不可欠でした。
全社標準との不整合
CI/CD、IaC、セキュリティチェック、監視運用など、全社標準に合わせることが難しい状態でした。
言語選定：なぜGoを選んだのか
移行にあたり、まず「VBScriptの代わりにどの言語で再実装するか」を検討しました。全社標準のPython・Java・Goを候補とし、AWS上で動作するコンテナバッチを前提に比較しました。
起動性とコンテナ効率
Goは単一バイナリで配布でき、イメージを小さくできるため、小さなDockerイメージと速いコールドスタートを実現しやすいという利点があります。短時間のバッチ処理における スパイク（突発的なバッチ処理増加やトラフィック急増）を想定していたため、起動性×軽量性を最優先にしました。
並行処理のしやすさ
goroutineやchannelなどの機能が標準で備わっており、複雑なスレッド管理やロック設計を最小化できます。大量の商品情報を扱うバッチ処理に適していると判断しました。
学習コストとチーム適性
構文はシンプルで、習得も容易です。ライブラリも豊富で、コードレビューやテスト（table駆動など）も標準化しやすい点が魅力でした。
留意点
Goが常にJavaより高速とは限りません。一般に、Goは軽量バッチやスタンドアローン・ユーティリティに向き、Javaは長期稼働の大型サービスやJIT最適化が効くワークロードに強いと整理できます。もっとも今回は軽量バッチ／短時間処理／コンテナ配布という用途であり、Goのトレードオフが優位だと結論づけました。
結論として、中間ハブ的な連携バッチでは、起動性・軽量性・学習難度の低さを総合評価し、Goを採用しました。
インフラ移行：WindowsサーバからAWSへ
Windowsサーバを残したままAWSと接続する方法も、技術的には可能です。しかし、運用・将来性・コストの観点から、クラウド移行（いわゆるLift&Shift）を選択しました（以降は「クラウド移行」で統一表記）。
運用コストの最適化
常時稼働のサーバから、必要時だけ動かすFargateベースのコンテナ実行へ移行しました。ピーク時はスケールし、平時は最小構成で抑制でき、無駄の少ない課金体系に寄せられます。
再現性と変更容易性（IaC/CI/CD）
CDKやTerraformでインフラをコード化し、GitHub Actionsと統合。ビルド→テスト→脆弱性チェック→デプロイまで自動化しました。これにより変更の高速性と監査可能性を両立しています。
可用性と監視
マルチAZ構成とCloudWatchによる統合監視で、復旧時間の短縮とボトルネックの早期発見を実現しました。ダッシュボード／アラートは環境ごとに用意し、閾値を環境差分で管理できるよう整備しています。
セキュリティ
アプリケーションにはgovulncheck、IaCにはcdk-nag、コンテナにはECR イメージスキャンを導入し、「動く」だけでなく「安全に動く」ことを基準に据えています。
コンテナ基盤の選定：なぜECSなのか
候補はEKS（Kubernetes）とECSでしたが、最終的にECS（Fargate）を選択しました。
クラスタ運用コストの最小化
サーバやクラスタの管理なしでコンテナを実行できます。ノード容量計画やOS/Patch、アドオン更新といった負担を大きく削減でき、Kubernetes運用そのものを背負わない選択にしました。Kubernetesに長けたメンバーがチーム内に多くない状況でも運用可能です。
Lambdaの制約を回避
執筆時点（2025年9月現在）、AWS Lambdaには最大15分（900秒）の実行時間の制限があります。長時間の処理や外部依存の待ちが発生するバッチ処理では不利となるため、ECSを採用しました。一方で、実行時間が短くイベント駆動でトリガー可能な処理（例：小規模なファイル変換や通知処理）については、Lambdaを併用する構成を検討しています。
スケーリングとイベント対応
大規模セールイベント（例：「本気のZOZO祭（セールイベント時のアクセス急増）」）のような突発的な負荷増加にも、オートスケーリングで柔軟に対応できます。プラットフォームアップデートの影響も受けにくく、変化に強い基盤を構築できます。
運用設計のポイント
- 二重起動の防止／冪等性：DynamoDBで実行コントロールを行い、リカバリ時に手作業でコード変更しない運用に。
- メンテナンス対応：外部依存先ごとのメンテナンス状態をDynamoDBで管理。
- 可観測性：ログ相関ID、メトリクス（件数／遅延／失敗率）、ダッシュボードを“誰がいつ見ても分かる”粒度で標準化。
結論として、クラスタ運用を極小化し、Lambdaの時間制限を回避しました。そのうえで、スパイクに合わせて伸縮できる要件に最適だったのが、ECS + Fargateでした。
まとめ
本記事では、リプレイス初期における意思決定を再現可能な比較観点に落とし込みました。
- 言語：Goを採用（軽量・起動性・並行処理に強い）。
- クラウド移行：IaC/CI/CDとセキュリティ標準（
govulncheck、cdk-nag、ECR イメージスキャン）を先に整備し、速さと安全性を両立。 - 実行基盤：ECS（Fargate）でクラスタ管理を手放し、Lambdaの15分制限を回避。
現在も開発が進行中で、一部のバッチ処理はすでにリリース済みです。今後もリプレイスの過程で得た知見を追加記事として公開予定です。本記事が、読者の皆さまの環境における「評価観点をそのまま参考にできる」内容になることを目指しています。
ZOZOでは、一緒にサービスを作り上げてくださる方を募集中です。ご興味のある方は、ぜひ採用ページをご覧ください。
