概要
あるトレーサビリティシステムは、NTTコミュニケーションズ社（以下、NTT.Com）提供のクラウドサービス「ECL1.0」上で稼働していますが、NTT.Com社からECL1.0のサービス終了（2023年12月1日）のアナウンスがあり、サービスを継続して提供するため、Amazon Web Services（以下、AWS）へのシステムリプレースを行いました（2023年6月、無事に本番運用してきました）。
当該システムの移行作業により、AWS上でのインフラ構築およびアプリケーションの設計に関する一連のノウハウが得られました。これらの作業は今後他のユーザーシステムの移行にも活かせるため、以下に記載します。
1）Flexible InterConnectを利用して接続し、マルチクラウド環境を構築
2）AWSセキュリティ設計（WAF、ACM利用）
3）EC2 AMIに存在しないDebian6システムのサーバー作成（VM Import利用）
4）SESリレーサーバーの構築
当トレーサビリティシステムの主な機能は以下の通りです。
1）全国2000台のハンディターミナルと顧客サーバーへのデータ送信、連携
2）顧客サーバーとwebサーバーとの出荷、製造データ連携
移行後構成
設計ポイント【1】
各店舗はハンディターミナルを使用して毎日発注しています。各店舗には合計2000台ほどのハンディターミナルがあり、それぞれ固定IPアドレスが登録されています。お客様（本部様）にAWS移行後のサーバーのIPアドレスを案内し、2000台ほどのハンディターミナルのIPアドレスをそれぞれ変更していただくよう依頼する場合、影響範囲が広すぎます。誤って変更したり、変更が漏れたりすると、店舗の発注業務に影響が出てしまいます。また、リプレース後、本部様のPCからサーバーにアクセスして分析業務を行う必要があります。IPアドレスを変更する場合、お客様がドメインを管理しているお名前.comの情報を変更する必要があるため、お客様自身で変更していただく必要があります。
Network Load Balancer（NLB）は、毎秒数百万のリクエストを処理できる優れた機能を持っています。アベイラビリティーゾーンの各ロードバランサーノードは、このネットワークインターフェイスを使用して静的IPアドレスを取得できるため、リプレース後のサーバーの前に、プライベート用のNLBを作成しました。このNLBのIPアドレスは、現行の固定IPアドレスと同じように使用され、ハンディターミナルからAWSサーバーへのクラウド専用線を介したセキュアな通信が行われています。VPC内においてインターネットに公開されていないサブネット内部のサーバを負荷分散する「内部」のNLBを使用することで、ハンディターミナルに登録されているIPアドレスは変更されず、店舗の発注業務に影響がない状態で、リプレースを進めることができました。
設計ポイント【2】
会員サイトVPCでは、NLBを介して会員サーバーへのアクセスが行われています。移行前はデータセンターで、FortiGateがWebリバースプロキシサーバーとして動作し、セキュリティ面で優れていました。しかし、AWS移行後、NLBは第7層（L7）アプリケーション層でのセキュリティ対策が不足しているため、セキュリティに対する不安の声が聞かれます。
NLBのターゲットグループに所属しているEC2のセキュリティグループを設定することで一定のセキュリティ対策は行っていますが、現行システムと同じく第7層（L7）アプリケーション層でのセキュリティ対策を維持したい場合、NLBのターゲットをALBに変更し、ALBを介して会員サーバーへのルーティングを行うことで対応可能です。ALBはAWS WAFを適用できるため、より強力なセキュリティ対策が可能です。AWS WAFは、Webアプリケーションの通信をフィルター、監視、ブロックでき、通信の中身を解析して特定の条件にマッチする通信を検知・遮断できます。また、WAFによるブロックされたIPアドレスなどのログをS3に出力し、Athenaを使用してS3に蓄積されたログを分析し、セキュリティに関するレポートを提出することができます。
設計ポイント【3】
移行前の会員サーバーはDebian 6を使用していますが、当該サーバーのアプリケーション対応は外部に委託しており、費用の関係から、OSは現状のままでなければならない制約があります。しかし、AWS Marketplaceサイトで確認したところ、Debianの提供は現在、バージョン 10および11のみだと確認しています。具体的なAMI（Amazon Machine Image）の一覧を取得する方法は以下の通りです。
$ aws ec2 describe-images --owners 379101102735 --filters "Name=architecture,Values=x86_64" "Name=name,Values=debian-jessie-" "Name=root-device-type,Values=ebs" "Name=virtualization-type,Values=hvm" --output table --query 'sort_by(Images, &CreationDate)[].[CreationDate,Name,ImageId]' --include-deprecated --region ap-northeast-1
| CreationDate | Name | ImageId |
|---|---|---|
| 2015-04-26T00:35:19.000Z | debian-jessie-amd64-hvm-2015-04-25-23-22-ebs | ami-ce5594ce |
| 2015-06-07T13:22:28.000Z | debian-jessie-amd64-hvm-2015-06-07-12-27-ebs | ami-e624fbe6 |
| 2016-02-19T14:58:10.000Z | debian-jessie-amd64-hvm-2016-02-17-ebs | ami-899091e7 |
| 2016-04-03T13:18:55.000Z | debian-jessie-amd64-hvm-2016-04-03-ebs | ami-d7d4c5b9 |
| 2016-09-19T15:39:44.000Z | debian-jessie-amd64-hvm-2016-09-19-ebs | ami-1f4a9a7e |
| 2016-11-14T14:27:10.000Z | debian-jessie-amd64-hvm-2016-11-13-1356-ebs | ami-50ed4631 |
| 2017-01-15T12:44:31.000Z | debian-jessie-amd64-hvm-2017-01-15-1221-ebs | ami-dbc0bcbc |
上記のDescribeImagesの結果から、Amazon EC2においてはDebian 6の古いバージョンは提供されていませんが、仮想化環境からAmazon EC2にVMをインポートする機能「VM Import」を利用することで、Debian 6のEC2インスタンスを問題なく構築できました。
具体的な手順は以下の通りです：
・Debian 6のVMWareサーバーを構築し、VMイメージを取得します。
・VMイメージをAmazon S3にアップロードします。
・VM Import機能を利用して、EC2 AMIを作成します。
・作成したEC2 AMIを使用して、Debian 6のEC2インスタンスを起動します。
この方法により、Debian 6のEC2インスタンスを問題なく構築することができます。
設計ポイント【4】
先日、Googleはスパム対策強化の一環として、2024年2月からGoogle宛にメールを送信する際のセキュリティ要件を厳しくすることを発表しました。当サービスでは会員様へのメール送信にDebian6のメールサーバーを使用しており、これは当サービスが稼働を開始して以来、利用されている古いサーバーです。このため、Google宛にメールを送信する際に新たなセキュリティ要件を満たすためには、新しいメールサーバーに切り替える必要があります。切り替えを行わない場合、Google宛のメール送信でセキュリティ要件を満たせなくなり、メールが正常に届かなくなる可能性があります。
アプリケーション側で最小限の変更で対応する必要があり、現在の会員サーバーはNATインスタンスを経由してメールを送信していますが、NATインスタンスにPostfixを導入し、AWS SESをリレー先として設定しました。これにより、会員サーバーからNATインスタンスへメール送信を依頼し、NATインスタンスはAmazon SESを利用し、送信する形になります。また、未達のメールがあり、バウンスメールが発生した場合、オレゴンリージョンでSESメール受信機能を活用し、返ってきたメールをS3に出力するように設定しました。尚、バウンスレートが高くなる場合、送信制限になりかねないため、バウンスレートは別途監視しています。
2023年6月に本番運用を開始して以来、トラブルなくサービスを提供し、お客様からのご好評を頂いております。