AWSの導入を取り巻く8つの不安

　スターバックスではまず、オンプレミス環境のシステム強化を検討した。しかし、ハードウェアの調達と設置に時間を要することや、機器の入れ替えに24時間にもわたるサービス停止が発生すること、コストがかさむことが分かった。また、打ち合わせなどの間接作業が増えたことにより、システム開発やビジネス計画にも影響が出てきてしまった。それでも状況の改善はあまり見込めなかったという。

　「オンプレミス環境でビジネスを続けていくには、システム拡張のたびに手間や時間がかかる。何よりもシステム管理者の負担が大きい」（野溝氏）ことから、Amazon Web Services（AWS）の導入を検討した。

　AWSの導入に当たっては、大きく8つの不安があった。スターバックスでは、それらの懸念事項に対して、7カ月を費やして準備や対応を進めた。以下では、そうした不安を解消するためのさまざまな取り組みを抜粋して紹介する。

AWS移行でスターバックスが抱えた不安と心配《クリックで拡大》

その1：既存システムはAWSで動くのか

　オンプレミス環境で運用してきた既存システムを、AWSのクラウド環境にそのまま移しても正常に動かないのではないかという不安があった。そこで、実際にAWS上に検証環境を構築し、動作検証を実施した。既存システムのハードウェアやネットワークの構成、アプリケーション構成、リソースの使用状況を整理。検証中にサーバのリソースを正確に把握するため、1台の物理サーバに集約していた役割を個々の仮想サーバに分散した。

　検証結果は、OSの一部変更と、アプリケーション・ミドルウェアの配置を変更するのみで、プログラムには変更を加えなくても動作することが確認された。

その2：レスポンスに問題はないか

　クラウド環境のレスポンスについても不安があった。テスト環境で実際に測定した結果、オンプレミス環境の方がレスポンスが良いケースが多かった。ただし、クラウド環境とオンプレミス環境で内部処理に差はなく、外部システムとの通信部分でギャップが発生していた。体感上は分からない程度の差であったため許容することにした。この点については「個別にジャッジが必要だ」（野溝氏）という。

その3：英語のコンソールは使えるか

　AWSへの移行を検討していた当時は、管理コンソールがまだ日本語に対応していなかった。ただ、既に日本語の解説資料が豊富にあり、AWSのパートナー企業の技術ブログなどを参考することで、英語版の管理コンソールの利用に困ることはほぼなかったという。ちなみに、AWSの管理コンソールは2015年4月から日本語版が利用できるようになっている。

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

　障害発生時の切り分けを課題や不安に感じるケースも多い。AWSのインフラ、OS、ミドルウェア、アプリケーションのどこに障害が発生しているのかを把握するのに時間がかかるのではないかと不安視していた。実際に試験運用中に幾つかのトラブルに遭遇したという。

　その際、インフラ部分に関する障害は「AWS サポート」による対応が迅速だった。「Amazon Elastic Compute Cloud（Amazon EC2）」の障害なら仮想マシンを再起動するだけで正常なハードウェア環境への移動が容易なため、ハードウェアに関する障害はすぐに復旧できることが分かった。また、OSや広く利用されているミドルウェアについてもサポート対象であるため、かえって障害の切り分けが効率化された。

その5：社内で運用できるのか

　AWSのサービスは、インフラやネットワークの管理以外の領域も含まれる。今までインフラベンダーに委託してきたこうした業務の一部を社内運用に切り替える必要があった。そこで同社では、次の3つの対策を講じた。

1. 運用フロー・手順書の整備：権限の設定方法や申請の手順を明確化
2. リファレンスアーキテクチャの作成：ネットワーク、セキュリティ、可用性、ログ管理と監視、バックアップについて、SLAごとに推奨の設定／構成を記載
3. 運用の一部自動化：最新の構成情報の自動取得、変更情報の検知をスクリプトで実装。AWS環境の管理を効率化

その6：運用コストは上がらないか

　野溝氏は「AWSは長く使うほど、オンプレミスよりもコストが高く付いてしまう」という話をユーザー企業から聞いていたという。この懸念に対しては、AWSのプロフェッショナルサポートの協力の下、システムの資産と運用コスト、サービスレベルを分析し、さらに利用時間についても加味することで、長期的に利用した場合でもコスト面でプラスになるという結果となった。

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

　パブリッククラウドはオンプレミスより危ないのではないか、という心配もあった。ここでも、AWSのプロフェッショナルサポートからAWSのセキュリティ機能を用いたベストプラクティスを幅広く提示してもらった。その中から、自社の環境やコストに見合ったものを組み合わせることで、オンプレミス環境と同等以上のセキュリティを確保することができた。

その8：AWSの有効活用

　インフラをAWSに移行するだけでも一定の効果は期待できるものの、アプリケーションをAWS環境に最適化することで、さらなるコスト削減と可用性の向上が見込める。そこで次の4つのアプリケーション改修を実施した。

1. 密結合の軽減：システムの負荷を低減し、システムダウン時のリカバリが容易になった
2. 1サーバ1ロール：機能ごとにリソースの消費状況が分かりやすくなった。特定の機能だけスケールアウトしたり、サービスを止めずに停止／起動することも可能に。ただし、コストや管理の手間が増える可能性もある
3. ミドルウェア／アプリケーションの自動起動：EC2でインスタンス障害が発生した際に、気軽にサーバの再起動ができるよう、自動起動する設定にしている
4. システムログの集約とS3への退避：障害時の調査効率が向上。ログを「Amazon Simple Storage Service（Amazon S3）」に退避することで、インスタンスのディスク容量を抑え、コストを削減している

“LINE砲”に耐え得るシステム基盤を実現

　AWSを利用することで、サーバの調達期間とコストを改善した。既存ネットワークであれば、数営業日でサーバの追加が可能になった。既存サーバのコストについても、稼働するサーバ台数が倍ほどに増えたにもかかわらず、総コストでは若干低下しているという。サーバの構築費用は自分たちで設定できるようになったため、ほぼゼロになった。

　また、新規開発案件では精緻なサイジングを事前にする必要がなくなり、その代わりに可用性やメンテナンス性の高いシステム基盤を検討することなどに時間を割けるようになった。ビジネスサイドからの要求にも迅速に対応できるようになった。そして、Webサイトへの予測可能なアクセス増には、先手を打って事前にシステムをスケールアウトすることでリソース不足が発生することはほぼなくなった。それにより、サーバの高負荷によるサービス障害が起こらなくなった。

　「2015年4月から期間限定でLINEの公式アカウントを運用している。5月に240万ほどの登録ユーザーへメッセージ通知を行ったところ、ブランド公式サイトへの過去最高の同時アクセス数を記録した。いわゆる“LINE砲”を受けても問題なくさばくことができた」（野溝氏）

　今後については、CRM基盤でのAWS活用やPOSシステムとの連係など分析基盤の強化を検討している。具体的には「Amazon Redshift」や「Amazon Elastic MapReduce（EMR）」の活用を考えているという。また、AWSサービスに最適化したアプリケーションの改修を続け、オンプレミス環境にある残存サービスのAWS移行に着手する。AWSでの新規サービスの開発も進めていくとしている。