行ってきました re:Invent。ミクシィグループで他の方のレポート ^1 ^2 も出ていますが今回は日本語でも英語でもほとんど情報がでていないセッション、 ARC214 - Addressing Your Business Needs with AWS をご紹介します。

ラスベガス入りして 3 日目、とにかく会場が広くて疲れ気味だったことから Tuesday Night Live は体力的に厳しいと判断、裏番組のこのセッションへの参加を決めました。

謎のセッション

そもそも、このセッションはスライド ^3 以外に全く情報がないのですが、これには以下のような理由があると思われます。

AWS の利用が浅い (もしくはまだ利用していない) 方が多く参加していた。このような参加者は twitter や blog でセッションの内容を報告しにくい
新機能発表の場ではない。拡散したくなる情報がない
Tuesday Night Live の裏番組の時間であり、参加者の絶対数が少ない (30 人程度)
ずっとディスカッションしていて twitter やる暇がない

セッションの目的は自身の経験をシェアし、他の AWS 利用者とのコラボレーションを深めましょうといったところです。

unconference とは

まず冒頭、このセッションは unconference スタイルで進めますよという説明があります。 unconference とは、

参加者相互のディスカッションが中心
話題に制限を設けない

前提でのグループディスカッションのことです。 re:Invent の他のワークショップがほとんどハンズオン形式で進むのに対し、このセッションは参加者相互のディスカッションによって成立するものです。つまり、このセッションの約 2 時間、議論を理解した上で発言が求められます。理解できなくても時間が過ぎていく他のセッションとは一味違います。

議論のはじまり

ファシリテーターとなった講師の進行で、各自の自己紹介からセッションがはじまります。SNS mixi を AWS に移行した経験があったので、「おれたちはでかくて古い perl のプログラムをオンプレから AWS に移したんだぜ」で自己紹介を乗り切りました。同じグループには、世界的に有名なハードウェアベンダのセキュリティアナリストもいました。その後各テーブルで各々が直面している課題や興味のあるトピックを出していきます。「オンプレをフォークリフトアプローチ (構成をなるべく変えずにそのまま AWS に持っていく) で移してしまったので、マネージドサービスへの移行に課題感がある」という感じ。

ひととおりテーブルごとに課題を出し終わった段階で、各テーブルでディスカッションした内容を報告しあい、問題となっているテーマを大きなくくりでまとめます。ここで出たおおきなテーマのくくりごとに、テーブルを移動してさらに議論を深めます。

マネージドサービスへの移行を課題として出していたので、「 migration/integration 」のテーブルに移動。ここで驚いたのは、「まだ AWS への移行をはじめていない」というユーザが多数派だったことです。 AWS のヘビーユーザが多くを占める re:Invent でこのような人々が集まることは、珍しいことだといえるでしょう。

あるあるネタ

各参加者が報告した課題は以下のようなものでした。

B2B でユーザ企業がクラウドへの移行を許してくれない。また、メリットが説明できない
データ移動に規制がある。EU 、中国と複数の地域の参加者から
コストが問題

クラウド利用にあたっては一般的に意識される問題でしょう。これに対して出た意見は以下のようなものでした。

たしかに、クラウドにあるかどうかって顧客にとってはどうでもいいことだよね
コスト、仕方ないよねー、おれも高いと思う (「GCP にしたらやすくなるかもよ」、はぐっとこらえた)
EU や中国でも、各地域のリージョン使えばデータ移動規制は遵守できるんじゃないの?

など。

我々はどうしたのか

今回、特にデータセンタから AWS への移行をどうしようかという方が複数おられたので、mixi の AWS 移行で実施した以下の経験を話しました。

AWS Direct Connect でデータセンタと VPC をつないで移動させやすいアプリケーションサーバから検証、移動をはじめた
仮に AWS への移行が頓挫したとしても、オンプレでの構成を維持できる状態で検証を進めた
アプリケーションサーバに比べて動かしにくい DB の移行は最後に回した。ここで、Aurora や RDS も検証したが、結局は mysql を EC2 で動かすことを選択した

特にデータストアの移行を後回しにし、AWS への移行が失敗した場合のリスクを最小限にするアプローチについては interesting というコメントをいただけました。また、「それって遅延とかだいじょうぶだったの?」という質問をいただき、 memcached を VPC 側にも作って read のトラフィックは VPC と DC の中で完結するようにしたよという回答をしています。