はじめに
GoQSystemでエンジニアをしている田添です！先日、2025年6月25日（水）、26日（木）の二日間、幕張メッセで開催されたAWS Summit Japan 2025に参加してきました！
自分自身はこれまでAWSを使用した経験は、個人・業務両方でほとんどありませんでした。ここ最近、業務でAWSを利用することがあり、あまり詳しくない状態からキャッチアップをしつつ取り組んでいたので、最高のタイミングで参加することが出来たと思います！
1日目は自分の業務領域や関心領域に関わりそうなタイトルと概要からセッションを選び、2日目はセキュリティ関連のセッションを中心に聴くことにしていました。
顧客データに関わるエンジニアの方、全員必見！“明日から使える” Customer 360 x AI の実践アーキテクチャー
このセッションでは流通小売業のビジネスに関わる方や複数のシステムにある顧客データを活用したい方へ向けてCustomer 360というサービスをどう活用するかについてでした。
販売員がお客様から引き出したカスタマープロファイルを元に、一人ひとりの好みに合わせて商品を販売することができれば、お客様の満足度が向上します。しかし、それらを一人ひとり丁寧に行うためには時間や人員といったリソースを増やさなければなりません。Customer 360というサービスを使うことで得られる効果としては、ロイヤリティの向上やライフタイムバリューの増加などが挙げられます。
Customer360のサービスを利用することで、詳細な行動履歴に基づいたリアルタイムのアプローチが可能になります。
従来は、お客様の情報をPOSや業務システムを通して収集して整理していくうちに、同じ人物が異なる人物としてデータ化され保存されていることが多くあります。例えば、登録内容の表記揺れ（例：名前を漢字で登録している、ひらがなで登録している）などです。
Customer 360はこのような問題を解決してくれます。例えば、「メールアドレスが基準値のパーセンテージを超えていたら同一人物として扱う」というルールづけを行うことで、従来異なる人物として扱われていたデータを、同一人物として扱うことができ、複数のシステム間で顧客データの連携を可能にします。
顧客データを活用するためのAWS事例として「名寄せ」の事例をもとに紹介をしてくださりましたが、GoQSystemでもたくさんの顧客データを契約者が利用する機能があり、その部分でこういったCustomer 360などの機能を活用できると良いのではないかと考えました。
“後発優位”で挑んだ 「いい部屋ネット」再構築： 4 年間の AWS 移行で実現した成果とその舞台裏
このセッションでは「いい部屋ネット」のWeb部分にスコープを絞って、４年間かけてオンプレミスからAWSに完全移行した道のりのお話でした。「いい部屋ネット」では、ビジネススピードが上がりづらい開発環境、インフラ費用などのコスト増加、アプリケーションの安定性の低下など、課題が山積みの状況で「強く、止まらないサービス」へ刷新することを強く望まれていました。
こういった大量の課題の改善にあたっては、小さなKPIを設定し、スモールスタートで改善を加えながら、数値の変化を検証していくことが重要だとお話しされていました。
AWSへの移行戦略として、ビジネス課題を意識した改善を行いながら、ストラングラーパターンによる移行を策定し、進められたそうです。ストラングラーパターンとは、既存のシステムを少しずつ新しいシステムに置き換えていく段階的な移行方式のことです。
最後に総括として、AWSへの移行それ自体を目的とせず、ビジネスゴールを達成することを意識して、スモールスタートで始めることを重視し、先行事例や蓄積されたベストプラクティスをフルで活用することが大事であると話され、セッションは閉じられました。
GoQSystemでも、レガシーな環境をどのようにモダン化していくかは、ビジネス目標と照らし合わせて進める必要があり、このセッションを参考に考えてみたいと思いました。
tenki.jp に学ぶセキュリティインシデント発生時の即応に必要な事業判断とエッジサービス活用
このセッションでは、大規模トラフィックサービスでも対応が困難な DDoS 攻撃の実態、対応時のプランニングやビジネス判断に求められる視点、そして AWS およびそのエコシステムを活用したインシデント対応の強みについてお話でした。
tenki.jpは日常的に50〜150万セッション/時のトラフィックを処理しており、大規模地震や警報級の台風接近時でも安定サービスを提供してきました。そのため、過去に攻撃を受けてもほとんど影響がありませんでした。
しかし、断続的な攻撃によってサービスに繋がらない状態が複数回発生したそうです。この時の攻撃手法は複雑かつ巧妙化されており、対応がなかなか追いつけない状況に陥っていたようです。
インシデント対応を適切に行うために、まずは課題の切り分けと優先度設定を行なったそうです。その上で、CDNとWAFの導入を進めることとなり、「稼働中システムへの容易か」、「継続改善を支えるエコシステムが存在するか」を選定ポイントに設定し、複数サービスの比較検討を行なったそうです。
| 短期的 | 中期的 | 長期的 | |
|---|---|---|---|
| GOAL | 一刻も早い通常稼働へ回復 | 未発事象を視野に防衛策を導入 | オペレーション改善の定期実施 |
| Requirement | 効果より即応性 etc. | オペレーションの容易さ etc. | 重要だが緊急ではないため特に定めず |
| Adopted | 既存インフラ・クラウド上で 即応できる追加対応を選択したが 結果的に不十分に |
必要な機能・検証要件を精査し 最適な新サービスを導入 |
継続的なオペレーションとして チューニング/モニタリング実施 |
tenki.jpでは、大量トラフィック処理の効率性と高頻度の情報更新への柔軟性という相反する要件が課題となっていましたが、複数の候補の中からこれらを両立できる Amazon CloudFront と AWS WAF を導入したことで、DDoS 攻撃を受けても安定してサービスを提供し続けられるようになりました。
最後に総括として、DDoS攻撃に限らずサイバー攻撃は大規模化・複雑化していることを指摘し、インシデント対応の判断にはエンジニア視点だけでなくビジネスサイドのポリシーも取り入れて合意形成を図ることで、より適切な選択が可能になるとの内容でセッションは締めくくられました。
常時大量のトラフィックを処理するサービスが「繋がりにくくなる」ほどの攻撃を受けた際の対処方法として、AWS活用事例を伺い非常に興味深く感じました。サービスを提供するものとして日々のトラフィック監視やインシデント対応はもちろんですが、長期的な視点でどのように運用を継続していくかという点についても、本セッションは大変参考になりました。
おわりに
セッション以外にも、AWSの活用事例として展示されていた様々な応用事例やデモなども空いた時間に見て回っていましたが、どれも非常にボリュームがあり、全てじっくり見ようと思うと1日2日じゃ足りないくらいでした。
初めて参加したAWS Summitは様々なことを学ぶ良い機会だったと思います。今後AWSを活用するにあたって、今回学んで得られた知識・経験を業務などにしっかりと活かせるように日々邁進していきたいと考えています。
