前例がないから発生する、想定外の課題

　こうして見ると、レコチョクは特に大きな問題もなくオンプレミスからAWSへの移行を成功させたように思えるが、それまで組織の誰も触ったことがなかったAWSを導入するとなれば、やはり想定外の課題が発生する。セッションの後半、松嶋氏は移行中に発生した課題を幾つか挙げ、それにどう対応したかをベストプラクティスとして紹介している。

協力してくれる社員がいない　→　キーマンをAWS re:Inventへ連れて行く

　「システムエンジニアには“猛獣”が多い。だから組織にはその猛獣を扱う“猛獣使い”が必要」と松嶋氏。オンプレミスに慣れきった猛獣たちをAWSに目覚めさせるための最も効果的な方法として猛獣使いの松嶋氏が選んだのは、自らがそうだったようにre:Inventという強烈な刺激を与えることだった。「旅費は1人当たり40万円程度。予想通り、それまでAWSを懐疑的に見ていた猛獣がre:Inventでころっと変わった」と松嶋氏は振り返る。技術者にはやはり最先端の技術を見せるのが効果的なようだ。

AWSの知識にばらつきがある　→　ガイドラインや診断項目を用意

　前述したようにAWSに関する知識が組織に蓄積されていない状態で始めたプロジェクトであるため、「現場任せにするとチェック項目が増える」（松嶋氏）という事態が発生しがちだった。そこでレコチョクでは、コンポーネントの命名規則やセキュリティポリシー、運用ポリシー、障害対応時のフローなどを定めたガイドラインを構築し、それに沿った運用を徹底している。また、新たにシステムを設計したり環境構築をしたりする前のチェック項目を定めた「アーキテクト診断」、リリース前にチェックをする「利用開始前診断」を実施している。

図2　レコチョクのAWSガイドライン（左）、図3　アーキテクト診断をしたシステム構築例（ダウンロードシステムで利用）《クリックで拡大》

AWSによってSLAが下がるシステムがある　→　SLAを含めてシステム見直し

　松嶋氏は「AWSによってサービスレベルが下がる」例として、「Oracle RAC（Real Application Clusters）」を挙げている。AWSはOracle RACを代替するような無停止コントローラーを提供していない。だが「そもそも無停止が必要なのかということを考えたとき、ユーザー企業ではほとんど必要ないのでは」という結論に至ったとしている。一概には判断しにくいが、利用中のシステムのSLA（サービスレベル保証）を再度見直すことは無駄な作業ではないはずだ。

アーキテクチャの構成の仕方が分からない　→　エンタープライズサポートがおすすめ

　AWSの最上級サポートプラン「エンタープライズサポート」を契約することで、アーキテクチャに関する質問に迅速に回答してもらえると松嶋氏はこれを推奨している。米国のAmazon本社からエキスパートが来日したときなどは「鮮度の高い情報交換ができる」（松嶋氏）という。

　「今回のAWS全面移行で、レコチョクが技術の会社、AWSの大規模なユーザーであることが示せたと思っている。時々、『レコチョクはオワコン』のような陰口を言われるが、決してオワコンではないと強調したい」とセッションの最後を締めくくった松嶋氏。今後は、過去15年分の配信データを活用すべく、「Amazon Kinesis」や「Amazon Elasticsearch Service」「Amazon Machine Learning」などを取り入れ、ビッグデータのリアルタム分析に投資していくという。最先端の技術の集合体であるAWSにインフラを全面移行し、新たなクラウドサービスをも積極的に取り入れる――変化の激しい音楽産業の世界において“技術の会社”として生き抜いていく原動力をAWSが与えている事例だといえる。