WEBVTT 00:00.120 --> 00:04.200 講師：クラウドの利用が組織にとって適切なソリューションであると判断したら､ 00:04.200 --> 00:06.350 次の決断は､ 自社でホスティングするか､ 00:06.350 --> 00:10.530 サードパーティからホスティング・ソリューションとして契約するかです｡ 00:10.530 --> 00:12.360 ソリューションをオンサイトでホスティングする場合､ 00:12.360 --> 00:15.030 これはしばしばオンプレミスと呼ばれる｡ 00:15.030 --> 00:21.660 オンプレミスのソリューションを使うのはセキュリティの観点からは素晴らしいが､ 00:21.660 --> 00:24.480 非常にコストがかかる｡ 00:24.480 --> 00:26.730 さて､ オンプレミス・ソリューションを使用することに決めた場合､ 00:26.730 --> 00:29.220 組織のクラウド・ソリューションの運用に必要なすべてのハードウェア､ 00:29.220 --> 00:34.260 ソフトウェア､ 人員を調達する必要があることを意味する｡ 00:34.260 --> 00:36.210 これに加えて､ データセンター用の施設も必要で､ 00:36.210 --> 00:39.480 すべての機器を収納し､ 適切に動作するための十分なスペース､ 00:39.480 --> 00:43.950 電力､ 冷却を提供する必要がある｡ 00:43.950 --> 00:48.480 このため､ 多くの組織がホスト型ソリューションの使用を決定している｡ 00:48.480 --> 00:49.531 ホスティング環境では､ 00:49.531 --> 00:56.280 サードパーティのサービス・プロバイダーが､ クラウド・ソリューションの維持に必要なすべてのハードウェアと設備を提供する｡ 00:56.280 --> 00:57.240 これは多くの場合､ 00:57.240 --> 01:04.860 複数の組織がクラウド・ソリューションを単一のサードパーティー・プロバイダーの施設内でホスティングするマルチテナント環境で行われる｡ 01:04.860 --> 01:07.080 例えば､ アマゾン､ マイクロソフト､ グーグルはすべて､ 01:07.080 --> 01:11.250 組織が利用できるホスティング・ソリューションを提供している｡ 01:11.250 --> 01:15.240 アマゾン・ウェブ・サービス（AWS）の例を考えてみよう｡ 01:15.240 --> 01:17.200 このマルチ・テンデンシー・ソリューションは､ 01:17.200 --> 01:24.210 同じ物理施設にある同じ物理ハードウェアを利用して､ 多数の多様な組織をサポートする｡ 01:24.210 --> 01:26.340 もちろん､ ホステッドプラットフォーム内では､ 01:26.340 --> 01:28.646 データを安全に保ち､ 他の組織に公開されないよう､ 01:28.646 --> 01:31.740 論理的な分離が行われている｡ 01:31.740 --> 01:33.810 しかし､ 機密を厳守したい情報がある場合は､ 01:33.810 --> 01:42.750 サーバーへの物理的・論理的アクセスをすべて制御できるオンプレミス・ソリューションを利用した方がはるかによい｡ 01:42.750 --> 01:48.390 マルチテナンシー・ソリューションを使用している場合､ 他のテナントと同じ共有リソースを使用しているため､ 01:48.390 --> 01:54.600 サーバーの弾力性が上方または下方に拡張され､ アクセス・サーバー容量のプロビジョニングとプロビジョニングの解除が行われると､ 01:54.600 --> 01:58.500 組織の残余データが他のテナントに公開される可能性があります｡ 01:58.500 --> 02:00.600 ホスティング・プロバイダーを利用することを決めた場合､ 02:00.600 --> 02:08.580 その認証と認可の仕組みを理解し､ 要件を満たすのに十分な保護が施されていることを確認することが本当に重要です｡ 02:08.580 --> 02:10.920 また､ 冗長性とフォールト・トレランスの対策が､ 02:10.920 --> 02:15.510 あなたが必要とするレベルに達しているかどうかも問い合わせる必要がある｡ 02:15.510 --> 02:18.630 ホスティング・プロバイダーに関するもうひとつの懸念は､ その所在地だ｡ 02:18.630 --> 02:21.630 あなたのデータはいったい世界のどこに保存されるのか？ 02:21.630 --> 02:25.920 その場所に基づいて､ どのような法律があなたの組織とそのデータに影響を与えようとしているのか？ 02:25.920 --> 02:31.170 これらは､ あなたの組織のためにホスティング・サービス・プロバイダーを選ぶ際に理解しなければならないことである｡ 02:31.170 --> 02:32.430 オンプレミス型かホスティング型か､ 02:32.430 --> 02:39.870 どちらを選択するかは決まったが､ 最後の決断は､ どのようなサービスを購入するかだ｡ 02:39.870 --> 02:43.260 現在､ クラウドサービスには主に3つのモデルがある｡ 02:43.260 --> 02:44.760 これらは､ SaaS（Software as 02:44.760 --> 02:47.790 a Service）､ PaaS（Platform as a Service）､ IaaS（Infrastructure 02:47.790 --> 02:50.490 as a Service）である｡ 02:50.490 --> 02:56.100 サービスとしてのソフトウェアでは､ サービス・プロバイダーがあなたの組織に完全なソリューションを提供する｡ 02:56.100 --> 02:58.290 これには､ ネットワーク､ ストレージ・サーバー､ 02:58.290 --> 03:00.870 仮想化などのハードウェアのほか､ オペレーティング・システム､ 03:00.870 --> 03:09.420 ミドルウェア､ ランタイム､ データ処理､ エンドユーザーにサービスを提供するために必要なアプリケーションやソフトウェアが含まれる｡ 03:09.420 --> 03:12.780 例えば､ マイクロソフトのOffice 365やGoogle WorkspaceのDocsやSheetsを使用している場合､ 03:12.780 --> 03:26.280 これらはサービスとしてのソフトウェア・ソリューションとみなされ､ エンドユーザーがウェブブラウザから直接Eメールやドキュメント､ スプレッドシートなどにアクセスできるようになる｡ 03:26.280 --> 03:27.380 サービスとしてのソフトウェアのもう一つの良い例は､ 03:27.380 --> 03:30.900 TurboTaxとQuickBooks Onlineである｡ 03:30.900 --> 03:36.016 これらの会社は､ ウェブブラウザーを使ってオンラインでアクセスできる税務申告・記帳ソフトを提供し､ 03:36.016 --> 03:38.490 あなたに代わってすべてのソフトウェア､ すべてのハードウェア､ 03:38.490 --> 03:41.520 すべてのデータ保存要件を処理してくれる｡ 03:41.520 --> 03:42.600 しかし時には､ 特定のサービス・ニーズを満たすために､ 03:42.600 --> 03:47.850 カスタマイズしたアプリケーションやソフトウェアを構築しなければならないこともある｡ 03:47.850 --> 03:50.370 この場合､ サービス・プロバイダーは､ ネットワーク､ 03:50.370 --> 03:51.630 ストレージ､ サーバー､ 03:51.630 --> 03:55.170 仮想化などのハードウェアと､ オペレーティング・システム､ ミドルウェア､ 03:55.170 --> 03:58.920 ランタイム・アプリケーションを提供するだけでよい｡ 03:58.920 --> 04:01.232 しかし､ サービスとしてのソフトウェア・ソリューションとは異なり､ 04:01.232 --> 04:08.315 実際のアプリケーション・コードを作成し､ クライアントとサーバー間のデータ処理を担当することになる｡ 04:08.315 --> 04:11.280 Platform as a Serviceを利用すれば､ 04:11.280 --> 04:13.890 共有リソース､ 従量制利用､ 迅速な伸縮性､ 04:13.890 --> 04:19.410 高可用性､ ファイル同期など､ クラウドを利用するメリットを得ることができる｡ 04:19.410 --> 04:24.690 しかし､ ビジネスニーズに合わせて独自の開発をカスタマイズする能力もある｡ 04:24.690 --> 04:25.770 このモデルでは､ サードパーティー・ベンダーは､ 04:25.770 --> 04:37.830 特定のサービスを運営するために必要なハードウェアとオペレーティング・システム・ソフトウェアを組織に提供するが､ エンドユーザーに最も近いコードやアプリケーションを提供することはない｡ 04:37.830 --> 04:41.115 例えば､ あなたの会社が新しいウェブ・アプリケーションを開発する場合､ 04:41.115 --> 04:45.510 サードパーティのクラウド・プロバイダーが提供する開発プラットフォームがあるかもしれない｡ 04:45.510 --> 04:48.225 私の会社､ ディオン・トレーニングでは､ これを撮影している今､ 04:48.225 --> 04:51.870 実は独自の学習管理システムを一から開発している最中なのだが､ 基礎となるハードウェア､ 04:51.870 --> 04:59.220 ネットワーキング､ ストレージ､ オペレーティング・システムのレイヤーすべてに対処する必要はない｡ 04:59.220 --> 05:05.850 なぜなら､ 技術スタックの下方にあるデータベースからすべてを処理してくれるからです｡ 05:05.850 --> 05:12.094 私と私のチームは､ エンドユーザーである生徒が操作するソフトウェア・コードと､ 05:12.094 --> 05:18.240 生徒がコースを受講する際のデータ処理のみを担当します｡ 05:18.240 --> 05:20.070 アマゾンが私たちにサーバー､ 05:20.070 --> 05:24.300 オペレーティング・システムの設定､ そしてデータベースを提供してくれて､ 05:24.300 --> 05:25.830 私たちはその上に好きなものを構築して､ 05:25.830 --> 05:33.661 最終的なアプリケーションやソフトウェアをエンドユーザーである生徒たちに提供することができる｡ 05:33.661 --> 05:40.110 最後に取り上げるのは､ IaaS（インフラストラクチャー・アズ・ア・サービス）と呼ばれるクラウドサービスモデルだ｡ 05:40.110 --> 05:42.150 現在､ サービスとしてのインフラストラクチャーは､ 05:42.150 --> 05:48.690 サーバー､ ロードバランサー､ ストレージ・エリア・ネットワーク・コンポーネントなどのITリソースを必要なときにプロビジョニングする手段である｡ 05:48.690 --> 05:50.065 インフラストラクチャー・アズ・ア・サービスを利用すれば､ 05:50.065 --> 05:55.590 追加リソースを動的に割り当てることができる｡ 05:55.590 --> 05:56.970 しかし､ そのハードウェアをすべて自分で購入し､ 05:56.970 --> 06:01.302 運用するという長期的なコミットメントに頭を悩ませる必要はない｡ 06:01.302 --> 06:02.610 例えば､ 自社のウェブサイトをホスティングするために､ 06:02.610 --> 06:07.380 クラウドベースのウェブサーバーを新たに契約するとする｡ 06:07.380 --> 06:10.620 Amazon Web ServicesやAWSを使っている場合､ 06:10.620 --> 06:12.360 これをEC2と呼ぶだろう｡ これはElastic 06:12.360 --> 06:18.420 Cloud Computeのことで､ EC2インスタンスに適切な量のリソースを選択できるようになる｡ 06:18.420 --> 06:19.800 4つのCPU､ 16ギガバイトのメモリ､ 06:19.800 --> 06:22.170 500ギガバイトのストレージ､ あるいはそれが何であれ､ 06:22.170 --> 06:24.900 それが欲しいと決めたのかもしれない｡ 06:24.900 --> 06:27.750 そして､ AWSがハードウェアリソースを割り当て､ 06:27.750 --> 06:28.710 そのリソースにオペレーティングシステム､ 06:28.710 --> 06:33.090 ミドルウェア､ ランタイムをインストールする｡ 06:33.090 --> 06:36.840 しかし､ 時にはその境界線が曖昧になることもある｡ 06:36.840 --> 06:38.512 CompTIAの公式テキストとドキュメンテーションによると､ 06:38.512 --> 06:42.090 サービスとしてのインフラストラクチャーは､ 仮想マシン､ ストレージ､ 06:42.090 --> 06:48.030 ネットワーキングを含むハードウェアのみに焦点を当てている｡ 06:48.030 --> 06:49.380 とはいえ､ アマゾン､ マイクロソフト・アジュール､ 06:49.380 --> 07:01.530 グーグル・クラウドなど､ ほとんどのプロバイダーは､ 必要なリソースを選択する際に､ コンピュート・インスタンスにインストールするオペレーティング・システムを選択させ､ それを割り当ててくれる｡ 07:01.530 --> 07:02.490 例えば､ アマゾンのEC2インスタンスは､ 07:02.490 --> 07:05.730 Linuxのアマゾン・マシン・イメージがすでにインストールされた状態で自動的に起動することができ､ 07:05.730 --> 07:14.370 これには基本的なLinuxオペレーティング・システムが含まれているので､ ニーズに合わせて完全にカスタマイズすることができる｡ 07:14.370 --> 07:16.470 なぜこのような話をしたかというと､ ほとんどがハードウェアであるものを扱う場合､ 07:16.470 --> 07:24.243 オペレーティング・システムがインストールされているというだけでは､ 試験におけるサービスとしてのプラットフォームとは言えないからです｡ 07:24.243 --> 07:28.004 その代わり､ サービスとしてのインフラを選ぶことになる｡ 07:28.004 --> 07:30.690 サービス・レベルとしてのプラットフォームを実現するには､ 07:30.690 --> 07:34.170 ミドルウェアとランタイムをすべて含める必要がある｡ 07:34.170 --> 07:38.370 これには､ データベース機能､ ApacheやNGINXなどのウェブサーバー､ 07:38.370 --> 07:43.980 その他サービスを提供するために必要なサーバーソフトウェアやミドルウェアなどが含まれる｡ 07:43.980 --> 07:47.490 試験の場合､ サービスとしてのインフラやサービスとしてのソフトウェアであれば､ 07:47.490 --> 07:49.830 通常はかなり明確ですが､ サービスとしてのプラットフォームとなると､ 07:49.830 --> 07:53.340 少し難しくなります｡ 07:53.340 --> 07:57.503 そこで､ 試験で使うべきちょっとしたヒントをここで教えよう｡ 07:57.503 --> 08:00.540 サービスとしてのインフラ以上のものを見出すなら､ 08:00.540 --> 08:04.920 おそらくサービスとしてのプラットフォームを答えとして選びたいだろう｡ 08:04.920 --> 08:10.800 サービスとしてのソフトウェアよりも劣るものがあるとすれば､ やはりサービスとしてのプラットフォームを選ぶことになるだろう｡ 08:10.800 --> 08:12.930 なぜなら､ 左側にはサービスとしてのインフラ､ 08:12.930 --> 08:14.580 右側にはサービスとしてのソフトウェア､ 08:14.580 --> 08:17.010 そしてその中間にサービスとしてのプラットフォームという､ 08:17.010 --> 08:20.400 スペクトルの両端があるからだ｡ 08:20.400 --> 08:25.380 つまり､ サービスとしてのインフラストラクチャーは､ サーバーを運用するために必要なものすべてを提供してくれる､ 08:25.380 --> 08:26.580 ということだ｡ 08:26.580 --> 08:28.652 これには､ 電力､ スペース､ 冷却､ ネットワーク､ 08:28.652 --> 08:34.817 ファイアウォール､ 物理サーバー､ 仮想化レイヤー､ 場合によってはオペレーティング・システムなどが含まれる｡ 08:34.817 --> 08:37.380 プラットフォーム・アズ・ア・サービスでは､ オペレーティング・システムと､ 08:37.380 --> 08:41.730 私がインフラストラクチャー・ソフトウェアと呼んでいるものを追加することになる｡ 08:41.730 --> 08:43.673 このインフラストラクチャー・ソフトウェアが､ 08:43.673 --> 08:45.600 ミドルウェアでありランタイム環境だ｡ 08:45.600 --> 08:47.070 つまり､ アパッチ・ウェブ・サーバー､ 08:47.070 --> 08:52.122 MySQLデータベース､ プログラミング言語などのことだ｡ 08:52.122 --> 08:54.510 さて､ SaaS（Software as a Service）を扱う場合､ 08:54.510 --> 08:56.988 先ほど説明したインフラやプラットフォーム部分の上に追加される､ 08:56.988 --> 09:01.530 ホストされたアプリケーション・ソフトウェアを扱うことになる｡ 09:01.530 --> 09:09.240 このように､ サービスとしてのソフトウェアは､ サービスとしてのプラットフォームやサービスとしてのインフラよりもエンドユーザーに近い｡ 09:09.240 --> 09:13.530 そのため､ ITプロフェッショナルとして､ 組織の要件に基づいてどのタイプのAs 09:13.530 --> 09:17.790 a Serviceが適切かを判断できるようになることが本当に重要です｡ 09:17.790 --> 09:19.260 このレッスンでは､ サービスとしてのソフトウェア､ 09:19.260 --> 09:23.660 サービスとしてのプラットフォーム､ サービスとしてのインフラストラクチャーについて話した｡