【レポート】レガシー脱却のための投資判断と移行～マーケティングのクラウドサービスでの全面AWS移行の実例～ #AWSSummit

AWS Summit Online Japan 2020

#レポート

#AWS

春田拓海 | Takumi

2020.09.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

DA事業本部の春田です。

AWS Summit Online絶賛開催中！ということで、本記事では「CUS-70: レガシー脱却のための投資判断と移行～マーケティングのクラウドサービスでの全面AWS移行の実例～」の内容についてまとめていきます。

セッション情報

株式会社シャノン技術統括部取締役技術担当堀譲治氏

15 年継続しているレガシーな B2B サービスを AWS に全面移行。どのように AWS 移行の投資を決済したか、移行のための技術戦略をどのように考えたか、顧客への説明をどうしたのか、社内のコミュニケーションをどうしたか、など実際に移行するときに課題になるポイントを弊社実例ベースでお話いたします。

※セッション動画は以下リンク

アジェンダ

はじめに
全面AWS移行投資の背景
移行の技術戦略をどう考えたか
移行前の開発
実際の移行でのポイントと苦労した点
社内および顧客コミュニケーション
移行の成果とまとめ

はじめに

会社概要
- 株式会社シャノン
- 設立: 2000年8月25日
- 所在地: 【本社】東京都港区三田3-13-16 三田43MTビル 4F
- 代表者: 代表取締役社長中村健一郎
- 事業内容: マーケティングクラウドの提供、関連するコンサルティング・アウトソーシングサービス
- Marketing is Science
- "テクノロジー"と"サイエンス"で、企業のマーケティングの課題を解決する会社
製品紹介
- デジアナマーケティングを実現するプラットフォーム
- デジタルとアナログの両方のマーケティングが実現可能な統合プラットフォーム

3つのオンラインイベントサービス
- プライベートショー、展示会、セミナーなど活用様々な場面に対応
- 3つのサービスの組み合わせで様々なイベントをオンラインで実現

全面AWS移行投資の背景

プロダクション環境でのAWS利用の障壁
- 2013年ぐらいから開発環境では積極的に利用
- 特に自動テストの並列実行などに利用していた
なぜプロダクション環境で積極的に利用してこなかったか？
- ①コスト
  - 以前簡易的に見積もった際に2-3倍くらいに膨れる見通しだった
- ②顧客側でのクラウドの許可がおりなかった
  - 金融業界のお客さんが軒並み拒否反応
  - 一部のお客様ではクラウド利用がダメということも
  - 社内の情報システムの壁を突破するのが非常に厳しい
全面移行検討のきっかけ
- ①インフラエンジニアが転職（社内の変化）
  - 10年弱に渡ってインフラをゼロから構築していたエンジニアが退職
  - 今後もデータセンター・HW・NWをメンテし続けるのか？
  - 今後長期的にインフラエンジニアを抱え続けることができるか？
- ②お客様のクラウドへの意識変化（顧客の変化）
  - FISC対応や金融業界の事例のおかげで、お客様のクラウド利用への敷居が下がってきた
- ③大規模マーケティングデータを扱えるようにしたいという事業サイドの要望（事業の変化）
  - コスト的にもRIを使えばいけそうな試算がでた

経営的判断のポイント
- サービスレベルがあがる
  - 当時、障害が多く発生していた
- 新しい収益が見込める（B2C、海外）
- コストが長期的には下がる
→ 競合に勝っていける
→ エンジニアリング面でのメリットも大事だが、事業にどのような好影響があるかを伝えるのが大事

移行の技術戦略をどう考えたか

移行戦略: リフトとシフトを同時に
- リフトだけでは意味が薄いと感じた
  - AWS自体はある程度実績があった
- マネージドサービスにすることでインフラエンジニア採用難を解決したかった
- 大規模な開発投資の決済を1回で済ませたかった

タイムライン: 全体約2年
- 本格的に検討をはじめて、計画立案から承認まで半年
- 移行のための開発に1年
- 80%のお客様を移行するまでに1年

コストシミュレーション: 移行期間中のコスト
- 「データセンター費用」「サーバの減価償却費」と「AWS費用」のバランスをコントロールしながら移行
- 移行期間中もトータルコストがあまり変わらないようにさせた（微増）
- 将来見通しも2年後にはデータセンターを逆転
- 1年のリザーブドインスタンスとオートスケールを活用して削減（夜間/休日の台数を最小化）

AWSのマネージドサービスに移行
- AWSへの移行にあたって多くの自社運用を止め、マネージドサービスに移行
- 最終的に約40種類利用
DNS
- BIND → Amazon Route53
FW/CDN
- SRX → AWS WAF
ロードバランサー
- Apache mod_proxy_balancer → Application Load Balancer
アプリケーションサーバー
- → Amazon ECS
キャッシュサーバー
- Memcached → Amazon ElastiCache for Memcached
- Redis → Amazon ElastiCache for Redis
DBサーバー
- Postgres → Amazon Aurora
- MongoDB → Amazon DynamoDB
ストレージ
- 商用ストレージ → Amazon S3

全体構成
- ベストプラクティスに従い、独自性を極力排除
- ある程度のスキルがあれば、誰でもメンテナンスが可能
- Mulit-AZで冗長化
- DBのバックアップに大阪リージョン
- マイクロサービスで構成

移行前の開発

実際に移行するもの → 事前に開発が必要な部分
- 対象のWebアプリ数 → 約30アプリ
- コンテナ化の対象数 → 約80種類
移行前に行った開発
- すべてをコンテナ化
  - 以前はAPサーバに福袋のようにたくさんのアプリが詰め込まれていた
  - 依存を小さくしないとオートスケールの安定的な運用が難しく、無駄も多かった
  - コンテナ化で開発効率もあげたかった
- すべてをCloudFormationに
  - 秘伝のスプリクト、謎の手順書を全てコード化して管理
- マネージドサービスにあわせてWebアプリを再開発
  - アプリで使用していたストレージをすべてS3に変更
- → 1,2名で約1年かけて開発
移行前に行った開発: 苦労したところ
- コンテナのヘルスチェックで落ちたら復帰させるために、1プロセス＝1コンテナが必要
  - バッチなどの内部ツールなども含めて全部コンテナ化する必要があり量が多かった
  - コスト、スケール、安定性の面で、プロセス管理の考え方を大きく変えた
    - 「オールインワンAPサーバが良い」　→　「1プロセス1コンテナが良い」
- データセンターの解約は3ヶ月前なので時期を変えられなかった

実際の移行でのポイントと苦労した点

実際に移行するもの → 本番の移行作業の対象
- 移行する顧客ドメイン数 → 約1400ドメイン
- 移行対象データのサイズ → DB: 8TB、ストレージ: 20TB
- データセンターから撤去したハードウェア → 約120台
リスクコントロールの基本方針
- コンポーネントごとに小さく移行
- 技術・経済リスクの小さい環境から移行
- 自社用本番環境は最初にやる
- マイルストーンの間隔は空け改善対応の期間をもうける
- → 失敗を前提にロールバック方針、スケジュール、体制を組む

本番データ移行プロセス
1. ストレージの移行
2. 1DBのWebアプリの移行
3. 顧客ごとにDBがわかれているものの移行
4. Webサーバの移行

1. ストレージの移行

以前の課題
- 20TBのデータがあり、商用ツールでうまくコントロールがきかず、いつも問題をかかえていた
- 改善を続け三重化をしていたものの事態は複雑になるばかり
- スケールが難しい。時間がかかる
- データが大きく対応にいつも時間が相当かかる
- 障害/トラブル対応の難易度が非常に高い

Amazon S3の移行
- 書き込みは非同期化、二重書き込み、同期を同時に実施
  - 書き込みエラーに対処しつつ、パフォーマンスの担保をはかった
- 読み込みはAmazon S3を見にいき、なければ旧ストレージを見る仕組みに
→ 20TBは停止して一気に移行できなかったため数ヶ月かけてライブでデータ移行

苦労した点
- 旧ストレージとの差分チェックのためにAmazon S3のAPIを使ったが、ファイル数が5億以上あった
  - Amazon S3のAPIは1回1000件しかひけず、差分確認に相当時間がかかった
- Amazon S3のAPIは数万回に1回ぐらいでエラーになりエラー時の対応をいろいろいれた
- パラレル実行で処理は高速化できたが、ネットワーク帯域の調整が必要だった
→ Amazon S3のAPIのエラーハンドリングと帯域調整に気を使った

2. Webアプリの移行

1DBにすべてのデータが入っているWebサービス群は段階的に移行
- 約30個のWebアプリを"一つずつ"移行
アプリは一つずつ必ず3フェーズで段階的に移行
- フェーズ1: AWSでAPサーバを立てて稼働
- フェーズ2: DBをAWSへ移行
- フェーズ3: DCの環境を完全に切り離す
→ 変更量を小さくして少しずつ移行し、リスクを軽減

3. データベースの移行

以前の課題
- データセンターではPostgreSQLをオンプレで利用
  - 某CTOにも「SaaSは絶対DBが死ぬ」っていわれててそのとおりだった
- スケールが難しい。時間がかかる
- 8TBありデータが大きく対応にいつも時間が相当かかる
- 障害/トラブル対応の難易度が非常に高い
- → システム全体の中で一番移行したかったのがDB!
Auroraを選定
- PostgreSQLのRDSではなく、Aurora PostgreSQLを選定
- 可用性が高い
- インスタンスとストレージが分離している
- ◎バックアップの信頼性が非常に向上したところが大きかった
  - ほぼタイムマシンのように過去のポイントに戻れる安心感が大きい
- ◎スケールアップが非常に簡単
  - パフォーマンスが必要な際も、インスタンスサイズをあげればいい
- PostgreSQLのアップグレードも非常に簡単になった
本番データ移行
- AWSのデータベース移行ツール（DMS: Data Migration Service)）を検討
  - 対象DBはLOBの列数が1テーブルに250あり多かった
  - text型やjson型を多数利用していた
  - 制限付きLOBモードがサイズ制限で使えない状況
  - 完全LOBモードでも移行時間がかなりかかるため問題になった
  - → ダウンタイムを確保した上で顧客ごとにdump/restoreを実施することに
- 本番データの移行は12週間に渡って実施
  - 週に3回の移行日を設けて、23時から7時の間で作業
    - 1日に移行できるDBサイズ量に限界があった
    - 週3回の深夜移行を12週間実施
  - → 分割して実施することで課題を解決しながら進めることができた

日付	合計DBサイズ	移行対象顧客
10月1日23時〜翌7時	54GB	a.smktg.jp xxx.smktg.jp aaa.shanon. co.jp …
10月2日23時〜翌7時	56GB	b.smktg.jp xx1.smktg.jp bbb.shanon. co.jp …
10月7日23時〜翌7時	48GB	c.smktg.jp xx2.smktg.jp ccc.shanon. co.jp …
10月8日23時〜翌7時	60GB	d.smktg.jp xx3.smktg.jp ddd.shanon. co.jp …

4. Webサーバの移行

移行前の状況
- 専用ドメインサービスがあり、顧客にIPアドレスを配布し、専用ドメインおよび専用のSSLの設定が可能だった
- CloudFrontへの移行に伴いお客様側でDNS等の変更作業が必要になった

CloudFrontに移行
- ApacheからCloudFrontに移行するにあたって、固定IPをなくしたのが影響大
- 実際の移行では失敗した場合に設定でDCにすぐ戻せるようにした
- → Webサーバの移行は顧客に大きな影響がでることがあり、余裕のある告知と入念な準備が必要

項目	移行前	移行後(CloudFront)
専用ドメインのIPアドレス	IPアドレス (Aレコード)	サービスURL(CNAMEで対応)	→ CloudFrontの固定IPは料金が高く選択肢に入らなかった
SPF	IPアドレスもある	ドメインのみに
FWでのIPアドレスの穴あけ	IPアドレスで対応	ドメインで対応が必要
SSL Cipher		CloudFrontでは以前と取り扱えるCipherが異なりエラーになるケースが
SNI(AWS Certificate Managerの利用)	未対応	対応しているクライアントしか接続できない	→ JavaやRubyなどからのAPI接続のSI で問題になった

移行作業の自動化
- DBとWebサーバの移行は顧客ごとに実施したため、作業回数およびそのチェック回数が膨大になった
- そのため完全に自動で分散実行できるツールを開発した
- 作業の最後は必ず目検での複数人チェックを行った
自動移行ツールの内容
- DB移行
- SSLの切り替え
- DNSの切り替え
- CloudFrontの作成
- システムの簡易動作確認
- 各フェーズごとのOK,NGステータスの管理
- 失敗してたら自動ロールバック
→ 作業が多いところは自動化しミスをなくす

社内および顧客コミュニケーション

移行のチーム体制
- 全社横断のAWS移行チームを組織編成
- チャットと定例でリアルタイムに近い形で状況を事業サイドにも共有
- 「なにかあればすぐ対処する」という約束を社内にして安心感を醸成

顧客対応の課題
- SaaSサービスだが、Webサーバの周辺で顧客側作業が必要な箇所があった
- お客様だけではなく社内の担当者もどうやって正確に移行状況を把握するか?
  - 1000以上に渡る顧客環境の移行ステータスが逐次変わっていく
- どうやってお客様社内で情報システム部門に正しく移行の技術的状況を伝えてもらうか?
  - お客様はITリテラシが必ずしも高くない

解決1: 顧客及び事業サイドがわかりやすい資料および管理画面チェッカーを用意

解決2: 地道な顧客行脚を実施
- お客様に技術的内容を伝えるのは大変
- 社内担当およびお客様担当は「DNS?SPF?」という状況で正しく伝える

移行の成果とまとめ

AWS移行の成果
- リリース
  - コンテナ化でそれぞれのアプリが完全に独立
  - CloudFormationで全部コード化
    - 本番適用もミスなし
- 運用
  - インフラの厳密な事前テストが可能に
    - 全く同じ構成を短期間に可能
    - CloudFormation化が効いてる
    - パフォーマンステストも低コストで
  - WAF、GuardDuty、Inspectorを導入し、セキュリティレベルが大幅に向上、運用も楽に
  - バックアップ精度が劇的に改善
- パフォーマンス
  - 従来数ヶ月かかってたスケールアップがすぐできるように
  - アプリのスケールアウトもコンテナ化により非常に容易に
  - オートスケール素晴らしい
  - パフォーマンスインサイト最高
コロナ禍での対応
- 新規事業としてバーチャル、オンラインイベント対応を実施
  - 大量の同時アクセスをさばけた
- 在宅でも問題なく運用が可能だった
  - データセンターまで行かなくていいのが本当によかった

AWS移行のまとめ
- 投資判断
  - 事業への収益影響におけるメリットを経営層で共有
  - 競合にこのままで勝てるのか？という危機意識を持つ
- 技術戦略と実際の移行
  - マネージドサービスを全面的に活用
    - クラウドネイティブにし、その後の運用コストを大きく削減
  - 小さくリリース、リリース間隔もあけて課題対応
  - 作業が多いところは自動化
- 社内と顧客
  - お客様作業が必要な場合は詳細に説明を
  - タイムリーな社内連絡・協力体制、社内の理解が非常に大事
  - 課題/障害は発生するので、それを前提とした対応社内と顧客