![[レポート]はじめてみよう!クラウドコンピューティングの A to Z #AWSRoadshow](https://devio2023-media.developers.io/wp-content/uploads/2016/10/awscr20161-400x400.png)
[レポート]はじめてみよう!クラウドコンピューティングの A to Z #AWSRoadshow
2016.11.24
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは、中山です。
2016年11月22日(火)ハービスホールにて行われたAWS Cloud Roadshow 2016 大阪に参加してきました。本エントリでは13:00からAWSトラックで発表されたはじめてみよう!クラウドコンピューティングの A to Z~ Getting Started with AWS Computing ~ というセッションの内容についてレポートしたいと思います。
資料
2016年12月5日追記
こちらのリンクから資料をご覧いただけます。
スピーカー
- 大場 崇令さま
 - アマゾン ウェブ サービス ジャパン株式会社
 - テクニカルトレーナー
- AWSの使い方をご紹介したり、今回のようにイベントでの登壇を主にしている
 
 
アジェンダ
- AWSの紹介と歴史
 - EC2について
 - AWSに於けるセキュリティの考え方
 - システムをスケールさせるサービス
 - 料金
 - 事例紹介
 
Amazonの歴史
- 1994年にオンライン書店として出発
 - 2006年にAWSを開始
 - 今年で10年目
 - この10年間、ものすごいスピードでアップデートを続けている
 - 2015年に722回のアップデートを実施
 - 2016年1月~2016年10月末までで782回アップデートした
 - 今年は1000回到達するかも
 - アップデートの数は総数で2677回
 
AWSの長所と強み
- 先行投資が不要、使った分だけ払う従量課金
- まだ資本力が弱いスタートアップ企業にとっては非常に魅力的
 
 - 規模の経済の利点
- 全世界規模でデータセンターを展開しているため、低コストでサービスを提供可能
 - 今までのサービス価格変更全てで値下げしている
 - 今日発表したのS3の値下げを含めて57回の値下げを実施
 
 - キャパシティプランニングが不要
- オンプレではバーストトラフィックを予想してそれに耐えうる設計をする必要があったが、往々にしてその予想は外れる
 - また、ピーク時の設計となるため通常のトラフィックではスペックの余剰が生まれてしまうというジレンマがある
 - AWSなら必要なリソースを必要な時に確保する仕組みを簡単に作れる
 
 - スピードとアジリティの向上
- オンプレでは数ヶ月掛かっていた構築も、AWSなら数〜週間で構築可能
 - 企業が力を入れるべきビジネスの本質な作業に時間を投資できる
 
 - データセンターの運用保守費が不要
- 運用コストの低減が期待できる
 
 - 分単位で世界中にデプロイ可能
 
AWSのコアインフラストラクチャとサービス
- オンプレでできてAWSにできないことは基本的にない
 - AWSでは70以上のサービスを提供している
 - 全世界にリージョンを展開
 - 各リージョンは最低2つのアベイラビリティゾーンで構成されている
 - アベイラビリティゾーンとはデータセンターをクラスタ化したもの
 - 各アベイラビリティゾーンは物理的に離れた場所にあるので高い可用性を実現
 - アベイラビリティゾーン間は専用線で接続されており非常に高速
 - 現時点で14リージョン/38アベイラビリティゾーン/64のエッジローケーション
 - 今後、中国/カナダ/イギリス/フランスで新リージョンを開設予定
 
EC2について
- クラウド上に仮想的にサーバを構築できるサービス
 - 数分で起動し、1時間毎の従量課金
- インスタンスの削除/アップデート/追加も数分で可能
 
 - 仮想サーバのことをインスタンスと呼ぶ
 - root権限はユーザで管理する
 - AMIというベースとなるイメージを元にインスタンスが起動される
- AMIには以下の情報が含まれている
 - インスタンスのルートボリュームの情報/OS/アプリケーション
 - 起動時にインスタンスにアタッチするボリュームを指定するブロックデバイスマッピング
 - 起動権限
 
 - AMIはAmazonが提供しているもの以外にも沢山の種類がある
- 各コミュニティが提供しているもの
 - AWS Marketplace
 - VM import/exportでオンプレ仮想サーバで稼働しているイメージをAMIにすることも可能
 - 自分でカスタマイズしたものをAMIすることもできる
 
 - EC2にはインスタンスのスペックをインスタンスタイプという概念で指定する
- インスタンスタイプは予め決められたものから選択
 - 各インスタンスタイプ毎にインスタンスファミリーというカテゴリが存在する
 - 各インスタンスファミリーはインスタンスの用途毎に汎用向け、CPUバウンド向けなどが用意されている
 - 世代という概念があり、最新世代では新しいCPUを利用できる
 - 例えば、c3.8xlargeでは「c」がインスタンスファミリー、「3」が世代、「8xlarge」がインスタンスサイズを表す
 
 - EC2のストレージにはEBSというNW的に接続されたブロックデバイスを利用する
- EC2とEBSはネットワーク経由で接続(ネットワーク接続型ストレージ)されているが、ユーザーはネットワークを意識することなく、高速にアクセス可能
 - EBSに保存されたデータは残しておくことが可能
 - スナップショットを取得してS3にバックアップすることができる
 
 - EBS以外ではインスタンスストアという、インスタンスが設置されたホストサーバ上のディスク領域が使える
- EBSとは異なりインスタンスを停止/削除すると、ここに保存していたデータもクリアされる
 - EBSと比較してより高速なI/O
 - スワップや一時的なデータ、キャッシュなどの消えても問題ないデータの保存場所として利用する
 - インスタンスストアの容量やスペックはインスタンスタイプ毎に規定されている
 - 追加費用はない
 
 - インスタンスにはライフサイクルという概念がある
- running/stopped/terminatedの3つがある
 - runningは実行中で課金対象、停止処理でstoppedに変更される
 - stoppedは停止中で課金されない、開始処理でrunningに変更される
 - stopped状態のときにインスタンスタイプを変更可能
 - temrinatedは削除された状態で停止/開始はできない
 
 
AWSに於けるセキュリティの考え方
- AWSには責任共有モデルという考え方がある
- AWSとそれを利用するユーザ間の責任範囲を定めたモデル
 - AWSはクラウドの基盤そのものを担当
 - ユーザはその上で構築したOSやアプリケーションを担当
 - 言い換えると、基盤の管理/運用をAWSへまるっとおまかせし、ユーザは自分のシステム保護にだけ集中できる
 
 - AWSではさまざまなセキュリティを担保するサービスを提供している
- 例えばセキュリティグループというものがあり、これはインスタンスなどにアタッチ可能な仮想的なファイアウォール
 - インバウンド/アウトバウンドのトラフィックに対してアクセス制御できる
 - インバウンドはデフォルトでは全て拒否、アウトバウンドは許可されている
 - ステートフルなファイアウォールなので、戻りのパケットも自動的に許可される
 
 - インスタンスにログインする際の鍵の管理方式としてキーペアという仕組みがある
- ログインするときはパスワードではなく、キーペアを利用した公開鍵方式を採用している
 - 公開鍵はAWSが管理、秘密鍵はユーザ管理
 - 鍵がマッチしたらログインできる
 
 - IAMによるアクセス制御
- 各リソースに対するアクセス制御を集中管理できる
 - AWSアカウント内にIAMユーザというものを作成でき、このユーザにAWSリソースに対する権限を指定できる
 
 
システムをスケールさせるサービス
- AWS上に構築したサービスをスケールさせるサービスとしてELB/Auto Scaling/CloudWatchなどがある
 - ELBは仮想的なロードバランサでSSL証明書のターミネーション機能もある
- ELBにはCLB(Classic Load Balancing)とALB(Application Load Balancing)という2種類のロードバランサがある
 - CLBは基本的にL4レベルのロードバランサで一部L7レベルに対応
 - ALBは最近登場したロードバランサでL7レベルに対応している
 - ALBではHTTP2/Webソケット/パスベースのルーティングができる
 - ELBは内部的に複数ノードで冗長化されており、トラフィックに応じて自動でスケールする仕組みになっている
 
 - Auto Scalingはインスタンスのスケールアウト/スケールインを自動で行ってくれるサービス
- 起動設定/Auto Scaling Groupという2つの概念からなる
 - 起動設定ではAuto Scaling Groupで起動するインスタンスを指定
 - Auto Scaling Groupで起動設定に基づいたインスタンスをどの程度起動するのかなどを調整する
 - スケーリングポリシーでスケールアウト/スケールインする際の条件を指定する
 
 - CloudWatchでAWSリソースの利用状況をモニタリング
- CloudWatchには収集した各メトリクスにしきい値を設定可能
 - このしきい値をトリガとして特定のアクションを実行できる
 - アクションにスケーリングポリシーを設定すると、負荷状況などに応じて自動でスケールするシステムを簡単に作れる
 - 逆に負荷が収まったのでスケールインすることも可能
 
 
料金
- EC2インスタンスには3つの買い方がある
- オンデマンドインスタンス
 - リザーブドインスタンス
 - スポットインスタンス
 
 - オンデマンドはユーザが利用したいときに買えるタイプのインスタンス
 - リザーブドはある一定期間の継続利用を条件に割引された状態で利用できる
 - スポットはAWS内で利用されていないリソースに対して入札形式で買う方式
- 通常価格より大幅にコストダウンした状態で利用できる
 - ただし、入札価格がスポット価格を上回ると使えなくなる
 
 - それぞれ利用シーン毎に選択すると、コストを下げつつ安定したサービスの構築ができる
- 例えば、常時稼働するインスタンスはリザーブド、スケールアウト用にスポット、スポットの予備としてオンデマンドなど
 
 - AWSには見積ツールがあるので、料金の計算をするときはぜひ使ってみてください
 
事例紹介
- ミサワホーム
- オンプレとAWSをハイブリッドで利用している
 - オンプレとVPC間はDirect Connectを利用して接続
 - オンプレと比較して40%近くまでコストを下げられた
 - 今後のシステムは全部AWSで構築する予定
 
 - ジャパンネット銀行
- システムをAWS上に構築
 - 5年単位で考えると20%コスト近いコスト減
 - オンプレでは構築に6週間掛かっていたが、AWSでは2週間で構築できた
 
 
感想
スピーカーの方がとても分かりやすく発表されていたので、これからAWSを使い始める方にとってAWSのイロハが分かる資料だったと思います。










