SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

「AWS Summit Tokyo 2015」イベントレポート

スタバの会員向けサービスインフラ事例で学ぶ、AWS移行時の8つの懸念と解決方法

AWSに移行するまでの道のりと、8つの懸念の解決法

 当初、野溝氏は直面する課題に対して、オンプレ環境でのリソースの充実を図ることによって事態の解決を試みました。しかし負担が増える一方で状況の改善、解決には至らなかったそうです。そして次なる手として「クラウドを使ってみよう!」とAWSの利用に踏み切るわけなのですが、「ただ単純に、AWSに飛び込むことはできなかった」と語るように、AWSの採用に際しては8つの懸念があったと野溝氏は言及。それらの懸念と「7か月で対応した」対処方法についてそれぞれ解説を続けました。

懸念その1:既存システムはAWSで動くのか

 まずはそもそも、現行オンプレ環境で稼働させている各種アプリがAWS上でも動くのか?というもの。こちらについては、AWSのプロフェッショナルサービスを活用することで技術・環境・運用面に関する不安を全面的に解消。部分的な変更は必要だったものの、問題なく稼働することを確認できました。

懸念と対応 その1
懸念と対応 その1

懸念その2:レスポンスに問題はないか

 レスポンス面での不安についてはテスト環境を用意し、実際に測定することで検証を行いました。オンプレ環境の方がレスポンスとしては良いケースもありましたが、その差は許容範囲に収まるものでした。問題が内部処理ではなく、外部システムとの連携部分で発生していたということもあり、このようなケースは事象を個別に判断していく必要があると野溝氏はコメントしました。

懸念その3:英語の管理コンソールは使えるか

 2015年4月に発表された「AWSマネジメントコンソールの日本語対応」も記憶に新しいところですが、この懸念についてはAWSにおける日本語の解説資料などを参考にすることで特段困ることはなかったと言います。AWS公式ドキュメントやクラスメソッド社のブログ「Developers.IO」などが参考になったと野溝氏は活用したリソースについて紹介しました。

懸念その4:障害の切り分けが難しくならないか

 検証中にはいくつかの障害発生に直面することも。こちらについてはAWS SupportやCloudWatchで検知を行うことができました。OSや、代表的なミドルウェアの状況についてもAWSでサポートしてもらえるので「むしろ効率良く、AWSワンストップ体制で障害の切り分けができました」と、野溝氏はAWS化することのメリットを強調しました。

懸念その5:社内で運用できるのか

 運用面についても懸念が及びます。この点については、運用フローや手順書の整備を行い、運用の一部を自動化するなどして体制の強化を行いました。現在も運用体制や手順書については整備中とのことです。

懸念その6:運用コストは上がらないか

 コスト面においても、先述のAWSのプロフェッショナルサービスにサポートを依頼。さまざまな分析を行い、費用対効果が出そうなシステムから移行を行いました。

懸念その7:セキュリティ面での安全性について

 セキュリティについても、やはり関心度合い、懸念の領域としては占める部分が大きいです。この部分については状況や用途に応じたAWSのセキュリティ機能やソフトウェアサービスを導入することで対応を行いました。それぞれの要素を的確に見定めることで、オンプレ環境と同等以上のセキュリティを確保することに成功しました。

懸念その8:AWSの有効活用

 環境面だけでなく、アプリケーション面についてもAWSで稼働させるための対応を行いました。「密結合を軽減」「1サーバー1ロール」「アプリケーションの自動起動」「システムログの集約」という4つの観点に基づき、アプリケーション改修を行うことでアプリケーションも「AWS仕様」にモデルチェンジさせることに成功しています。

AWSの現在の利用状況と効果

 以上8つの懸念について、およそ7か月という期間で対応を行ったわけですが、「AWSを利用する前には不安や心配ごとがたくさんありました」と野溝氏は当時を振り返りました。その不安や心配ごとを払拭することに大きな役割を果たしたのがここまで幾度か出てきている「プロフェッショナルサービス」の存在です。検証フェーズを設けて、彼らのサポートを受けながら物事を1つずつ取り組んで行くことで、タフな移行作業を乗り切ることができました。

 ブランドサイトの使用回線帯域量の対策についてはオンプレで構成を組んだ場合、数百万円かかるとされたコストがAWSを使うことで数十万円に抑えることに成功したそうです。また、「LINE砲」と呼ばれる集中アクセスについても、同時30000以上アクセスを受け切れる体制を敷くことができているといいます。

 今後は「分析基盤を強化していく過程でRedshiftやEMRなどを活用していきたい。POSデータも活用したい。フロントシステムについてはさらに最適化を進め、AWS上での新規サービス開発も行う予定。もちろん、My Starbucksのサービスも今後拡大を進めていきます」と野溝氏は今後の展望についてコメントし、セッションを締めました。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
「AWS Summit Tokyo 2015」イベントレポート連載記事一覧

もっと読む

この記事の著者

しんや(シンヤ)

2010年末~2013年前半位までの期間で興味のある勉強会に頻繁に参加。参加してきた勉強会のレポートブログとTogetterをひたすらまとめ続け、まとめ職人(自称/他称含む)として暫く過ごしておりました。色々な縁あってDevelopers Summit 2013では『公募レポーター』も務めました。2013年05月『出張ブロガー』を経て2013年08月にクラスメソッド株式会社へ転職。現在は業務(AWS及びその周辺技術を扱う)の...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/8761 2015/06/18 14:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー