AWS の運用ノウハウを爆速で獲得する方法 #AWSSummit
こんにちは、岩城です。
2019年6月12日(水)〜2019年6月14日(金)の 3 日間にわたり、 千葉県の幕張メッセにて AWS Summit Tokyo 2019 が開催されています。
こちらで講演されたセッション「 AWS の運用ノウハウを爆速で獲得する方法」を聴講しましたのでレポートします。
概要
AWSには160を超えるサービスが存在しています。よって、AWSを初めて導入されるお客様が、各サービスの特性を把握し運用していくことは非常に困難です。本セッションでは、たった1つのツールを導入するだけでプレミアコンサルティングパートナーのノウハウを獲得し、AWS初心者でも簡単に運用負荷を軽減できる手法についてお話しいたします。
スピーカー
- 株式会社サーバーワークス 代表取締役社長
- 大石 良
- Fuji Xerox Asia Pacific Pte Ltd SWI Regional Solution Center Senior Executive
- 鈴木 達文
※敬称略
レポート
サーバーワークス
- 2000年に大学向け案内サービスを開始、60%のシェア
- 課題
- 毎年2月の朝に200台位サーバが必要だった
- それ以外の期間は無駄になっていた
- 2007年AWSのテスト利用開始
- 2008年社内サーバ購入禁止令
- 2009年AWS専業インテグレーターに転換
- 新規案件はAWSのみ
サーバーワークスが注目されたきっかけ(事例:日本赤十字社)
- 東日本大震災のため、日本赤十字社にアクセスが集中、サイトダウンした
- アクセス超過問題を解消するためボランティアで参画
- EC2を立ててCloudFrontにコンテンツをコピーし、オリジンサーバへのアクセスを減少
- 30分で構築、以降サイトのダウンは発生しなかった
- 上記実績を評価され義援金管理システムを立てることに
- 義援金の振込がすごく、当時最高スペックのインスタンスを20台、ロードバランサー、1日に500万通メールを送信する性能が求められた
- インフラを2時間、アプリケーションを48時間で構築
- 義援金受付開始まで
- 3/14 打ち合わせ
- 3/15 サイト復旧
- 3/17 義援金受付開始
プレミアムコンサルティングパートナー
- 日本円2.8兆円の市場
- 4段階のランク付け
- 世界88社、日本8社
- 今年上場
- 株価からもクラウドに期待されていることが分かる
オンプレ運用の世界
- やることがはっきりしている
- はっきりとした境界がある
クラウド特有の運用例
- コスト管理
- クレデンシャル管理
- オンプレとは異なるリカバリープロセス
- etc
コスト最適化
- 適切なリソース管理を行わなければ料金が膨れるリスクがある
- 利用していない時間帯の開発環境を停止
従来と違う監視スキーム
- オンプレ時代は1台のサーバが効果であるため、リソース監視中心
- 仮想サーバの調達が用意のため、サービス単位の関心が中心に
- NetFlixは生きている本番環境をデタラメにサービスを止めて、サービス全体としてヘルシーかをチェックしている
データ保護、クレデンシャル管理とリカバリー
- ストレージ種類によってことなる保護レベル
- データの保護に加えて、クレデンシャルの管理がより重要に
- リカバリープロセスもオンプレとは異なる
- 場合によっては環境を1から立ち上げ直した方が早い場合もある
セキュリティ
- 継続的コンプライアンス
- クラウドは頻繁に環境や構成が変化するので、導入時チェックすれば良いといわけではなく、定義したポリシーに従っているかリアルタイムでチェックし続ける必要がある
- 攻撃社からの攻撃だけでなく、メンテナンス作業のリソース停止忘れ、消し忘れを検知
クラウド運用の確立がなぜ難しいか
- オンプレ運用ノウハウだけではクラウドに対応できない
- オンプレと異なり常に進化するため、今日のベストが明日もベストとは限らない
- Amazonはリフトアンドシフト
- 現時点で設計しても、AWSの進化が早すぎて導入した時点で古くなり非効率的
- まずはリフトしてからシフトする
どうなるべきなのか、内製化?
- SIer、開発ベンダーへの不満
- スピードが遅い
- コストが高い
- 新しい提案を持ってこない
内製化の実際
- スピード
- 頭数以上のことはできない
- 優秀な人に業務が集中するため
- コスト
- 優秀な人材を採用するにはかなりのコストが掛かる
- 新しい取り組み
- 社内の人員でも新しいことを提案できるとは限らない
アメリカはIT技術者がユーザ企業にいる罠
- 実際は契約ベース
- 10年前の1万人と今の一万人では頭数は一緒でも中は違う、技術によって人が変わる
- アメリカは人口が増えており人材豊富
- 日本は人口が減っており人材不足であるため、同じことできない
オール内製化が合理的でない理由
- クラウド技術は既存の技術よりも圧倒的にアップデートの頻度が高い
- システム内製化のためにエンジニア数を補うことは困難
- 内製化のルーツである米国ではプロジェクト単位での雇用が一般的
運用=「車の運転」のようなもの
- 基本的に運転できた方が良い
- 移動時間の見積もりを立てたり、コスト間隔を習得することができる
- 車の運転は「移動するための手段」
- クラウド運用も「クラウドによってビジネス貢献する」ことが目的であって、運用そのものは目的ではない
サーバワークスが提供するもの
- AWS環境に特化した運用サービス
- AWSの運用を自動化するサービス
- 自社でも運用できるようにするためのスキルトランスファー
Cloud Automator
- ジョブ自動化
- 運用に欠かせないオペレーションの自動化
- バックアップ
- インスタンスの起動/停止
- AWSが標準で提供していない独自のアクション
- RDS、Redshiftの起動停止
- インスタンスの起動停止
- WorkSpaces の起動停止
シナリオ
- 定期実行が必要なバックアップ処理の自動化
- 業務時間外に開発用インスタンスを停止コスト削減
- 既存の監視、運用システムの監視
コストメリット試算(丸紅様の事例)
- 不要な時間帯にインスタンスを停止することで、5年間で2.7億円のコスト削減
構成レビュー
- AWSが推奨されるポリシーで運用されているか常に監視する
- MFAが設定されているか
- IAMユーザが個別にIAM Policyが適用されているか
事例1:実際に運用ノウハウを獲得した事例(Fuji Xerox様)
- AWSをどのようにお使いですか?
- 2014年からAWSを活用、お客様向けのアプリケーションやサービスの基盤として利用している
- そこで獲得したノウハウをお客様に提供している
- 選定した理由
- AWSを使う方が技術者がモチベーション高く、技術を楽しんで取り組める
- 世界一のインフラをお客様に届けたい
- 運用ノウハウの獲得にどのような工夫をされていらっしゃいますか?
- 管理している方々がプロフェッショナルになる時代ではない、色々なところから情報を得る時代、基本的にパートナーと一緒になって仕事を行う
- コミュニティをあちこちに作って顧客の声を吸い上げている
- 社内コミュニティをうまくまわすコツ
- 世界一のインフラであるAWSに対して、自分たちで興味を持って活動しているため、自発的な行動に任せている
- Cloud Automatorの感想
- 必須
- 忘れがちで忘れちゃいけないこと
- 何が目的か?管理運用することが目的ではない、お客様により良いサービスを提供することが重要
- 時間を掛ければ自社でできるが、時間が掛かる、いかにお客様に早くサービスを届けるかを意識しパートナーを利用する
- これからのクラウド戦略について教えてください
- これまでは日本の各地域に中小をターゲットにAWSを広めていた
- アジアパシフィックの土地が高い、今後所有することがなくなり、クラウド利用が加速するはず
- 日本でやっていたようにアジア・パシフィックにも届けていきたい
- ニュージーランドの市場が盛り上がっている、ナチュラルリソースが少ないのでパートナーを利用する流れが増えるはず
事例2:AGC
- 目標:情シスが迅速にプロトタイプが開発できるようにAWSを用いた開発スキルを部員が習得する
- サーバレス開発のトレーニング
- 認定資格を取得
- PoC環境を実際に構築
事例まとめ
- クラウドは本業に専念する時間を作るために活用するもの
- 実践的な運用ノウハウの獲得にはパートナーのサービスを活用しつつ、基礎的な運用スキルは自社でも取得
まとめ
- クラウドの運用はオンプレとは似て非なるもの運用時代の常識も変化する前提を組織で共有
- 運用は車の運転のようなもの、内製化をゴールにするのではなく、最短でビジネス目標を達成する
- クラウド運用ノウハウの獲得には、内製+外注に加え外部からのノウハウ獲得が近道