(レポート) AWS Cloud Roadshow 2015 大阪: UC-01「導入支援サービスの現場から見た、企業でのクラウド導入の勘所」 #AWSRoadshow

はじめに

本記事は、2015年12月2日(水)に開催されたAWS Cloud Roadshow 2015 大阪のセッション「導入支援サービスの現場から見た、企業でのクラウド導入の勘所」のレポート記事です。スピーカーはアマゾン ウェブ サービス ジャパン株式会社 AWS プロフェッショナルサービス本部 コンサルタント、千葉 悠貴氏。

レポート

AWSプロフェッショナルサービスとは

AWSクラウド導入を考えているお客様への支援をするサービス。
上流からテクニカルまで、お客様が課題と考えていることを全てご支援している。

これまでに導入を支援してきたお客様が感じていた課題を共有したい

オンプレミスにどういう課題があったのか？
何故AWSを使うことにしたのか？
AWSを使ったことによる変化。

クラウド導入検討の背景

メリットとして4点。Elasticity、Agility、Availabillity、Cost。
柔軟性。AWSであれば1時間単位でもいつでもすぐに使えるし、止められる。
　昼間しかいらない、夜中はいらないのであれば、サービスを止めればコストがかからない。
アジリティ。管理コンソールでボタンをクリックすればすぐに始められる。
可用性。
　S3であれば99.99%のように、高い可用性。
　AZを跨いだHA構成を簡単に構築可能。
コスト。
　継続的な値下げを実施。使った分だけ、最低限の出費で済む。

AWSを使い始めるために、どういう検討が必要か？

導入にあたって検討すべき事項。目的とゴール、社内規定、導入対象、実施体制。
目的とゴール。
　クラウドを導入する目的はお客様によって様々。コストであったりアジリティであったり。
　　明確なゴールと評価軸、定量的なメトリクスを設定する。
　　AWSを使うことでどんどん良くできるが、評価軸がないと測れない。
　　同じ軸で測ることで、どうやって改善されたのかを知ることが出来る。
　　優先順位を付ける。コストなのかアジリティなのか。第一優先のものをマストとして達成する。
　　定期的に測定し続ける。インフラは入れてお終いではない。いいスパイラルを回していただく。
社内規定の確認。
　大規模なお客様で一番最初に言われるのがここ。社内規定でクラウドが使えるのかを最初に確認。
　AWSと自社の責任分界点を明確にする。自分たちが何をするべきで、AWSが何をしてくれるのか。
　社内規定に合わなかった場合。目標次第で社内規定を変えたり作り替えたりする。
　業界によっては業界基準がある。金融など。社内だけでなく、業界基準も確認する。
導入対象の選定。
　AWSの技術制約を確認。例えば物理制約がある場合や導入ソフトウェアのサポート可否など。
　　AWSにそのまま全て持っていくのではなく、アーキテクチャの変更コストなども考慮する。
　業務用件の確認。社内システムの結合度。オンプレミスとAWS間のレイテンシなど。
　　場合によってはオンプレミスに残すという選択肢もあり。
　コストや移行合理性の確認。ランニングコスト、移行コストに対する費用対効果を算出。
　　コストだけではない。AWSのメリットと目標を加味して合理性を確認する。
　なんとなくクラウドを使ってみたい、だと回らない。
　　具体的な対象システムを意識し、クラウドに乗るのか乗らないのかを考える。
　　システムの種別が移行なのか新規なのか、攻めなのか守りなのか、によって導入ステップを分ける。
　　　やりやすいものから移行するのが早い。AWSのメリットであるアジリティを活かす。
　　コストと導入メリット。なぜクラウドを利用するのかを理解する。
実施体制。
　理想的な実施体制。意思決定者があり、担当者が関わっており、有識者がいる。
　　目的とゴールを共有し、モチベーションを維持し、PMが作業をディスパッチする。
　　AWSの有識者から担当者にAWSのナレッジを共有し、スキルを移管する。
　できる限り専任担当者を付ける。最初にこれを願いする。
　　専任担当者を付けたほうが、AWSのナレッジが溜まりやすい。
　　　お客様の中にAWSのナレッジを持っている人がいたほうが進めやすい。
　　AWS導入は簡単なだけじゃない、苦労することもある。作業にフォーカスする人が必要。
　各担当者の役割と責任を明確にする。
　AWSの有識者は最初はいない、AWS技術チームやパートナーを活用する。
　　コンサルティングパートナーは日本で119、テクノロジーパートナーもたくさん。
　　大阪のパートナーもたくさんいる。

AWSを使うことによる変化

クラウド導入は入れてお終いじゃない、入れた後に課題が出てくる。
よくある課題。AWS専任担当者に質問や作業が多発するパターン。
　喜ばしいことだが、AWSによってインフラのアジリティが高まったのに、人がブロッカーになってしまう。
　AWSだとハードウェアの調達コストがかからない。その分、人がボトルネックになるケースが目立ってしまう。
　次にやることは？構築や運用作業の効率化→標準化やカタログ化に取り組む。
　　実際、プロフェッショナルサービスを契約したお客様の半分以上が行う。
　標準化やカタログ化のメリット。
　　標準構成を定めることで導入作業の負荷を軽減。
　　セキュリティポリシーを満たした構成を即座に提供できる。
　　ベーシカルな質問の前捌き。AWSって何？みたいな質問はドキュメントで対応。
　標準ガイドライン例。
　　サービスレベル標準。求められる要件に応じたサービスレベルを定義。
　　標準的な構成。サービスレベルに合わせて可用性を確保した構成を定義。
　　環境構築の自動化。AWSの特徴であるプログラマブルなインフラ。標準構成を簡単に自動化出来る。
　　　CloudFormationの活用。
　重要なのは見直しとカイゼンを続けること。
　　AWSも変わる、お客様のシステムも変わる。定期的な見直しとカイゼンを続ける。
　使い始める前に、導入負荷軽減策を検討しておく。自動化など。
　ガイドラインを作成し、見直しカイゼンを続ける。

さらに上手く使うために

AWSのサービスは継続的に増えていく。
　ペースはどんどん上がっていく。新しいサービスが出ても追いつかなくなる。
現状でも50を超えるサービス。全部を知り尽くすのは不可能に近い。
　EC2、S3、RDSは標準的に使われる。それ以外のサービスはやはり少なくなる。
マネージドサービスの利用でどう良くなるか？クラウドネイティブ。
　クラウドネイティブ=クラウドが提供するサービスを前提に構築するシステム。
　　仮想サーバ上で1からアプリケーションを作るのは、ビジネスにメリットを与えない。
　　フルマネージドサービスを活用することで、ビジネスにメリットを生む。
　クラウドネイティブ化によりサーバーレスに出来る。
　　監視もバックアップもパッチ当てもいらなくなる。
　　セキュリティや可用性はAWSの責任範囲になる。
　クラウドネイティブのメリット。
　　アプリ開発者が楽になる。開発コストを最小化出来る。
　　必要に応じてEC2を使うことができる安心感。
　クラウドネイティブ化を阻む課題。
　　メリットはわかるんだけど、まだ早い。というお客様の声。ご意見。
　　新しい技術をキャッチアップする余力がない。既存システムの運用だけで手一杯。新しいサービスを覚えられない。
　　知らないものを使うのが怖い。
　　そもそも内製していないので、構築ベンダに追加発注が必要。
　　お客様の心理障壁を突破する方法はまだ見つかっていない。
MITメディアラボのJoi Ito氏の言葉。
　イノベーションを加速したければ、広げたければ、失敗した時のコストを最小化することだ。
　課題を感じるお客様は、失敗したくないお客様。失敗を恐れないことが必要。
　　AWSでは失敗した時のリスクが小さい。とりあえずやってみても大きなコストがかからない。
リスクの少ないシステムからクラウドネイティブ化を始める
　既存システムに手を入れるのが怖いのであれば、新規システムから。DBをAurora化。
　定期的なオペレーションをLambdaで自動化。
　社内用、チーム用のシステムでElasticsearch Serviceを使った検索システム。
　アプリ配備にCodeCommit/CodeDeploy。
　システム間の連携をSQSで疎結合。
　使いやすいところから、少しずつ試してみる。
　使ってみると、「こんなもんで使えるんだな」という印象を持ってもらえるお客様が多い。
　使ってみることで心理障壁を突破する。

まとめ

AWSは素晴らしいサービスをたくさん出しているが、あくまでツール。
　どう使うかは人、お客様次第。自分たちでどう使うかを考える。
　どう使っていいかが分からない場合はAWS技術チームやパートナーをうまく使う。