AWSアソシエイト試験に向けて2(サービスの種類と仮想化とクラウドの基礎知識）

サービスの種類

アンマネージド型構成(UnManaged)

スケーリング、耐障害性、可用性を利用者側で設定し管理する必要があるサービス。
設定は柔軟にできるが、その分管理が煩雑になる。

代表的なサービス……EC2(サーバー)

マネージド型(Managed)

スケーリング、耐障害性、可用性がサービスに組み込まれていてAWS側で管理してくれる。
要はパッケージされているようなものなので管理は楽だが、設定が限定的になってしまう。

代表的なサービス……Route53(DNS)

AWSのグローバルインフラ構成

• リージョン
• AZ
• エッジロケーション

の3つから主に成り立っている。
マクロな範囲の順に
リージョン > AZ > エッジロケーションとなる。

リージョン

国及びその地域におけるAWS拠点、日本は東京と大阪リージョン。
リージョンとリージョンとは物理的に独立しているので東京と大阪のリージョンは同じ日本の拠点であってもそれぞれ独立した拠点ということになる。
なので、基本的には運用する場合は1リージョン内でということになる。
しかし、例えば極端に言うと障害対策として別リージョンにクローンを作り、運用中のリージョンに障害が起きたら別リージョンに変えるということもできなくはなく、またリージョン間で通信する方法はあるので、一方のリージョンで障害が起きた場合別のリージョンから通信でデータを送ってもらう……ということも珍しいことではない。
例えば東京・大阪リージョンは隣接リージョンなので、広帯域の専用ネットワークで繋がっているので通信は可能である。

リージョンに応じてAWSサービスの利用可能状態や値段が異なる。
例えばバージニアリージョンは機能のリリースがいち早く行われるが、東京は同タイミングでその機能を使うことができなかったりすることがある。
リージョンの選択は要件に応じて、通常はサービスを行うにあたって身近な地域を選ぶ。
例えば拠点が日本である会社のサービスなら東京か大阪がベターということになる。
ただし、拠点が同じ国だとリージョン障害が起きた場合可用性は下がるリスクはある。
反面、拠点と違う国のリージョンを考慮する場合、その国の法律や事情を勘案した上で採用しないといけない。
(ex. 中国の場合、政府に求められたら情報はすべて提供しないといけないなど)
別リーションを選択する例としては、事業継続性計画(BCP)対策やデータ・予備システムを別リーションに作る……つまりは可用性を担保するという目的がある。

*BCP（事業継続計画）とは、企業が自然災害、大火災、テロ攻撃などの緊急事態に遭遇した場合において、事業資産の損害を最小限にとどめつつ、中核となる事業の継続あるいは早期復旧を可能とするために、平常時に行うべき活動や緊急時における事業継続のための方法、手段などを取り決めておく計画。

別リーションを作った場合、リージョン間との連携方法は以下のような手法がある。

• AWS Direct Connect Gateway経由での接続
• インターリージョンVPC Peeringでの接続
• EC2リージョン間でのAMIコピー
• S3リージョン間でのレプリケーション(レプリカを作ってリアルタイム同期する)
• RDSリージョン間でのリードレプリカ(DBの複製だが読み取り専用)
• DynamoDBリーション間でのレプリカライブラリ
• Route53DNSフェイルオーバー(運用中に異常事態が発生した際に、待機している別システムへ切り替える)

こうしてみるとすべて可用性・及び信用性に関わるものなのがわかる。

AZ(アベイラビリティゾーン)

リージョン内における複数の独立したインフラ拠点。
AZ同士は低遅延(Latency)で常にリンクしているという特徴がある。
1つのAZは物理サーバーの集合によるインフラであり、それを仮想化することでユーザーにサービスを提供する。
つまり、1つのAZのみで障害が起きるとサービスに影響が起こる可能性が高くなるので、複数AZでサービスを構成することで可用性と信頼性を確保するのがベター。
ただし、その場合以下の点に留意する必要がある。

• システム間の連携や共有が制限される
• 単一AZ内でしか共有されない設定が多く、連携するための設定が必要になる

エッジロケーション

キャッシュデータなどを利用する際のエンドポイントとなる拠点。
CloudFrontやLambdaエッジなどのサービスなどに使われている。

仮想化について

仮想化とは物理的インフラの構成を隠し、仮想化された単位に分けたり、あるいはそれらを統合させて利用できるようにする技術。
基本的な考え方としては1つの大きな物理サーバーがあって、それをストレージにおけるパーテーションのような形で分割してそれぞれリソースを提供するというイメージ。
例えばストレージとして提供された場合、それぞれストレージA,B,C……と個々に利用することもできるし、AとBを合わせて1つのストレージとして扱うようなこともできる。
物理サーバーを仮想化するソフトウエアとしてはVmWare型とハイパーバイザー型とがある。
以下仮想化の例である。

サーバーの仮想化

1台の物理サーバー上に複数のOSを動作させる。
ハイパーバイザー、VmWare、コンテナ(ex.Docker)といった型がある。

ストレージの仮想化

複数のストレージを仮想的に統合して1つの大きなストレージプールとする。
仮想化の段階としてブロックレベルかファイルレベルかといった違いがある。

ネットワークの仮想化

新たな仮想ネットワークの構築や制御をソフトウェアによって動的に実施する技術
SDN、VLANなど

デスクトップの仮想化

サーバー上においたPC環境のデスクトップ画面を遠隔地にある接続端末に転送する技術
仮想PC方式やブレードPC方式などがある。

仮想化のメリット

• 物理サーバーを調達する場合にかかる様々なコストの削減
• 構成の変更やメンテンナス対応に柔軟性が出てくる
• セキュリティの向上

仮想化の構成例

仮想化ソフトウェアを使う場合

例えば個人ユーザーにおいて仮想化を使う場合

• 物理マシン(自分のPC)
• ホストOS(使うOS)
• 仮想化ソフトウェア

という3つが土台となる。
その上に一例としてEC2インスタンスとして仮想化された

• ゲストOS
• ミドルウェア
• アプリケーション

という3つの構成が乗ることになる。

これがDockerだとEC2インスタンスの部分がコンテナとなるので

• 物理マシン(自分のPC)

• ホストOS(使うOS)

• Dockerエンジン

• ミドルウェア

• アプリケーション

という構成になる。
DockerはゲストOSを用いず、ミドルウェアの部分をコード化してファイルとして共有する。
このファイルによってミドルウェアのインストール及び環境設定が成されるので、誰でも即時に環境再現ができ、作成した環境も配布することで全員が同じ環境を共有できる仕組みになる。
当然、削除もコンテナを消すだけでいいので楽。
語弊はあるがPipEnvにおけるPipFileによる環境再現のようなイメージ(DockerにもDockerFileがある)

クラウド

必要に応じて他社所有のハードウェア・ソフトウェア等をネットワークを介して利用するシステム利用形態。
提供されるリソースは主に以下の3つに大別できる。

• アプリケーション
  ex. プログラミングソフトウェア、業務パッケージソフト、フレームワーク

• ミドルウェア及びOS
  ex. システム連携・セキュリティ・運用管理システム、Web/アプリケーションサーバー、DB、OS

• ミドルウェアは共通利用される機能をまとめたソフトウェアを指す

• インフラ
  ex. サーバー、クライアント端末、ネットワーク

でこのリソース郡をどこまで提供するかで大別したのが前回やったIaaS(インフラまで)、PaaS(ミドルウェアまで)、SaaS(アプリケーションまで全部)である。

クラウドの特徴

5つのサービス構成

• オンデマンド・セルフサービス(人を介さずに必要に応じてサーバー、ネットワーク、ストレージを設置・拡大・設定できる)
• 幅広いネットワークアクセス(ネットワークを通じて各種デバイスから利用可能である)
• リソースの共有(ハードウェアの使用容量などを複数利用者で共有し、利用者ごとの需要によって動的に割り当てられる)
• 迅速な拡張性(リソースは必要に応じて手動でも自動でも増減できる)
• 計測可能なサービスである(稼働状況が常に計測され、利用状況を可視化することでコントロールや最適化ができ、それに応じて従量課金を取ることができる)

クラウドの3つの提供形態

まずプライベートなのかパブリックなのかその中間なのかで分かれる。
要はサーバーをどこが持ってて、どう利用されるかという違い。

プライベートな場合

**オンプレミス(サーバー自社所有)**という形態。
その名の通り、自社でサーバーを所有しその上でハードウェアやソフトウェアを購入して使いシステムを構築する。
自社でハードウェアをコントロールできるが、反面物理サーバーの調達及び環境の構築・運用・維持にコストがかかる。

中間を取る場合

プライベートクラウドという形態
オンプレミスと同じで自社でサーバーを所有しクラウド環境を構築するが、ハードウェア・ソフトウェアは事業部や子会社で共同で利用する。
オンプレミスと比べてより自社資産を効率的に利用でき、下記のパブリックな場合と比べてコントロールも自由が効くがサーバーの調達に関わる問題は残り、クラウドの管理運用が難しいことからクラウドの利点(いつでもどこでも利用ができる)という点から考えるとメリットの低下に繋がる。

パブリックな場合

パブリッククラウドという形態。
外部クラウドによってハードウェア・ソフトウェアともに他社と共同利用する。
柔軟な環境構築・解除が可能である。
運用管理自体を他社に委任でき、システムの調達・構築の自由度が高いがその分リソースから他社依存なので自社コントロールは制限される。