WEBVTT 00:00.090 --> 00:02.880 講師：最近､ クラウド・コンピューティングはいたるところで見かけるようになりましたが､ 00:02.880 --> 00:07.290 それはクラウド・コンピューティングを使うことで非常に多くのメリットがあるからです｡ 00:07.290 --> 00:10.343 このレッスンでは､ クラウドのさまざまな特徴について話を始めるにあたり､ 00:10.343 --> 00:12.930 そこに焦点を当てることにする｡ 00:12.930 --> 00:15.160 クラウド・コンピューティングについて語るとき､ 00:15.160 --> 00:17.670 私たちがクラウドを使うことを選択したときに見える利点や特徴は､ 00:17.670 --> 00:19.680 ほんの一握りである｡ 00:19.680 --> 00:23.460 これには､ 高可用性､ スケーラビリティ､ 弾力性､ 利用率の測定､ 00:23.460 --> 00:27.540 共有リソース､ ファイル同期などが含まれる｡ 00:27.540 --> 00:29.040 これらを見てみよう｡ 00:29.040 --> 00:31.350 まず､ 高い可用性がある｡ 00:31.350 --> 00:37.800 さて､ 高可用性とは､ クラウドを利用しているときにサービスがほとんどダウンしないという事実を指す｡ 00:37.800 --> 00:39.690 なぜなら､ クラウド上に構築されるサービスのほとんどは､ 00:39.690 --> 00:43.200 高い信頼性と耐障害性を持つように構築されているからだ｡ 00:43.200 --> 00:45.900 つまり､ 高水準の可用性を確保できるということだ｡ 00:45.900 --> 00:47.610 さて､ 可用性に関しては､ 00:47.610 --> 00:53.760 通常､ 稼働時間の長さとダウンタイムの長さのパーセンテージで測ります｡ 00:53.760 --> 00:58.860 例えば､ ネットワークにおけるゴールドスタンダードはファイブナインと呼ばれる｡ 00:58.860 --> 01:06.390 ファイブナインは99を意味する｡ エンドユーザーが体験する999%のアップタイムまたは可用性｡ 01:06.390 --> 01:11.980 つまり､ ダウンタイムは毎年5分15秒程度しかない｡ 01:11.980 --> 01:18.570 そう､ 1年365日のうち､ たった5分15秒しかないのだ｡ 01:18.570 --> 01:20.400 そのためには､ 信頼性が高く､ 01:20.400 --> 01:23.430 可用性の高いシステムが必要だ｡ 01:23.430 --> 01:29.123 つまり､ ウェブサイトが1つあれば､ それをホスティングするウェブサーバーは少なくとも2つあることになる｡ 01:29.123 --> 01:30.300 つまり､ 一方がダウンしても､ 01:30.300 --> 01:32.160 もう一方が負荷を担っているため､ 01:32.160 --> 01:35.730 エンドユーザーはダウンタイムを経験しない｡ 01:35.730 --> 01:38.640 高可用性というのはそういうことだ｡ 01:38.640 --> 01:47.280 例えば､ 私のウェブサイトdiontraining. comでは､ クラウドサービスを使って非常に可用性の高いセットアップを実現しています｡ 01:47.280 --> 01:51.060 そのため､ 世界のどこからアクセスするかによって､ 世界中にある複数のサーバーのうち､ 01:51.060 --> 01:55.680 あなたに最も近いサーバーにアクセスし､ より良い体験を得ることができます｡ 01:55.680 --> 01:57.627 サーバーが何らかの理由でダウンした場合､ 01:57.627 --> 02:00.300 自動的に少し離れた別のサーバーにリルートされますが､ 02:00.300 --> 02:02.490 まだ稼働しています｡ 02:02.490 --> 02:04.980 そうすることで､ 求めているサービスを受けることができ､ 02:04.980 --> 02:08.460 高い可用性を確保することができる｡ 02:08.460 --> 02:10.590 これからお話しするクラウドの2つ目の特徴は､ 02:10.590 --> 02:12.480 スケーラビリティと呼ばれるものです｡ 02:12.480 --> 02:15.150 さて､ スケーラビリティについて語るとき､ 02:15.150 --> 02:17.370 これはシステム内の人数やモノの数を直線的な速度で､ 02:17.370 --> 02:23.220 あるいは直線的な速度以下で増やすことができるという事実を指している｡ 02:23.220 --> 02:24.053 どういうことかというと､ 02:24.053 --> 02:28.620 例えば100人のユーザーが私のシステムを使っているとしよう｡ 02:28.620 --> 02:31.282 もし200人のユーザーをシステムに入れたとしたら､ 02:31.282 --> 02:35.010 コストは20ドル以下になるはずだ｡ 02:35.010 --> 02:37.860 今､ 100人のユーザーが200人になり､ 価格が10ドルから100ドルになったとしたら､ 02:37.860 --> 02:43.380 それは指数関数的なスケールになり､ 私たちはそれを望まない｡ 02:43.380 --> 02:45.180 クラウドシステムを構築する際､ 私たちは常にスケーラビリティを追求しています｡ 02:45.180 --> 02:47.070 つまり､ 今日のユーザー数が10人であっても､ 02:47.070 --> 02:51.090 明日は100人になるかもしれないということです｡ 02:51.090 --> 02:52.590 その翌日には1,000人､ 02:52.590 --> 02:55.260 そのまた翌日には10,000人といった具合だ｡ 02:55.260 --> 02:56.093 フェイスブックやグーグル､ 02:56.093 --> 03:19.560 リンクトイン､ UNIといった大企業を見れば､ 毎日何百万人ものエンドユーザーが自社のプラットフォームにアクセスしており､ クラウド・サービスのスケーラビリティに基づいてスケールアップすることができる｡ 03:19.560 --> 03:20.970 さて､ スケーラビリティに関しては､ 03:20.970 --> 03:22.650 2つの方法がある｡ 03:22.650 --> 03:25.560 ひとつはスケールアップで､ これは垂直的スケールと呼ばれる｡ 03:25.560 --> 03:29.010 これは､ 特定のサーバーやノードにより多くのリソースを追加することである｡ 03:29.010 --> 03:32.970 例えば､ 2つの仮想CPUを持つクラウドベースのサーバーを使用している場合､ 03:32.970 --> 03:35.730 実際には4つの仮想CPUに増やすことができる｡ 03:35.730 --> 03:37.170 これがスケールアップの考え方だ｡ 03:37.170 --> 03:38.610 プロセッサーの増設､ RAMの増設､ 03:38.610 --> 03:43.110 ストレージの増設､ 帯域幅の増設など､ リソースを増やすのだ｡ 03:43.110 --> 03:47.100 一方､ 水平方向のスケーリングとして知られる拡大縮小もできる｡ 03:47.100 --> 03:49.440 小規模なマシンを使うことに変わりはないが､ 03:49.440 --> 03:53.400 ロードバランサーの背後でより多くのマシンが連動して動作する｡ 03:53.400 --> 03:55.080 つまり､ 1台のサーバーですべての負荷を処理し､ 03:55.080 --> 04:00.180 CPUを増やしたりメモリを増やしたりしてスケールアップするのではなく､ 1台から2台､ 04:00.180 --> 04:02.520 2台から4台､ 4台から8台へとスケールアウトし､ 04:02.520 --> 04:11.940 ロードバランサーの後ろにさらにサーバーを追加することで､ さらにトラフィックを処理できるようにするのです｡ 04:11.940 --> 04:15.864 さて､ ここで3つ目の領域､ 「急速な弾力性」について説明しよう｡ 04:15.864 --> 04:22.731 今､ 私たちが急速な伸縮性について語るとき､ それは私たちが非常に迅速にスケールアップまたはスケールダウンできるという事実について話している｡ 04:22.731 --> 04:25.454 これは､ アマゾン､ グーグル､ 04:25.454 --> 04:38.104 マイクロソフト､ その他の企業が所有する物理サーバー上の多くの仮想マシンで自動化とオーケストレーションを行っているためである｡ 04:38.104 --> 04:41.040 そして､ これが私たちに急速な弾力性をもたらしている｡ 04:41.040 --> 04:43.200 一般的に急速弾力性や弾力性という言葉を耳にしたら､ 04:43.200 --> 04:50.370 システムがリアルタイムで需要の変化に対応できる能力のことだと考えてほしい｡ 04:50.370 --> 04:54.780 では､ 私のウェブサイトdiontrainingを使う例に戻ろう｡ 04:54.780 --> 04:54.780 comに移籍した｡ 04:54.780 --> 04:56.490 今､ 私がウェブサイトをチェックし､ 04:56.490 --> 04:58.770 1,000人の生徒がログインしているとして､ 04:58.770 --> 05:00.330 今から5分後にチェックすると､ 05:00.330 --> 05:02.520 10,000人の生徒がログインしているとしたら､ 05:02.520 --> 05:03.774 私のシステムは追加のクラウドリソースをスピンアップし､ 05:03.774 --> 05:10.230 新しいユーザーからの負荷の一部を追加サービスにプッシュするように設計されている｡ 05:10.230 --> 05:12.810 それが急速な弾力性という考え方だ｡ 05:12.810 --> 05:16.470 一般的に､ クラウドで作業している場合､ 05:16.470 --> 05:18.949 システムを正しく設計していれば､ 05:18.949 --> 05:27.120 弾力性を持って素早くスケールアップすることができる｡ 05:27.120 --> 05:28.680 そうしたい理由は､ 余分なサーバーを増やすとコストがかかるからです｡ 05:28.680 --> 05:34.500 サーバーを持つほどのユーザーがいない場合､ そのコストを払いたくないので､ サーバーを解放してサービス・プロバイダーに返し､ 05:34.500 --> 05:40.140 そのサービスを他の誰かに貸し出すことになります｡ 05:40.140 --> 05:45.000 その代わり､ オンプレミス・モデルの場合､ 例えば今日1,000人の生徒がいたとします｡ 05:45.000 --> 05:48.150 まあ､ 1,000人の生徒のためには､ 3台のウェブサーバーが必要かもしれない｡ 05:48.150 --> 05:51.956 しかし､ 生徒数が1万人になれば､ さらに15台のウェブ・サーバーが必要になる｡ 05:51.956 --> 05:55.080 そのためには､ あと15台サーバーを買わなければならない｡ 05:55.080 --> 05:55.950 ラックに入れなければならない｡ 05:55.950 --> 05:57.270 すべてのソフトをインストールしなければならないし､ 05:57.270 --> 05:58.440 設定もしなければならない｡ 05:58.440 --> 06:02.222 そのため､ 私たちがその需要に対応するために規模を拡大することは､ 06:02.222 --> 06:04.980 弾力性の尺度ではあまり迅速ではない｡ 06:04.980 --> 06:07.860 成長が非常に遅いビジネスモデルであれば､ それでも構わない｡ 06:07.860 --> 06:12.171 しかし､ あなたが扱うものが高速であったり､ 現代のソーシャルメディアプラットフォームのいずれかであったりする場合､ 06:12.171 --> 06:23.880 あなたが行った何かがバイラルになり､ みんながあなたのウェブサイトを訪れて殺到し始めた場合､ 迅速にスケールアップする能力を持っていなければ､ そのバイラルな出来事からもたらされるトラフィックを獲得する能力を逃してしまうことになる｡ 06:23.880 --> 06:29.700 クラウドを利用することでそれが可能になる｡ 06:29.700 --> 06:32.910 4つ目は､ メーター利用である｡ 06:32.910 --> 06:36.510 さて､ これは先ほどの急速な弾力性の話に戻る｡ 06:36.510 --> 06:38.686 さて､ 従量制の利用について話しているとき､ 06:38.686 --> 06:43.800 私たちは利用ごとに料金を支払っているという事実について話している｡ 06:43.800 --> 06:46.650 データベースのような従量制のサービスを利用する場合､ 06:46.650 --> 06:47.730 ユーザー数や接続数､ 06:47.730 --> 06:52.050 保存されているデータ数に応じて課金されることがある｡ 06:52.050 --> 06:56.910 基本的に､ 私たちは消費されるサービスの実際の使用量に基づいて課金される｡ 06:56.910 --> 06:59.262 秒単位､ 分単位､ 1時間単位､ 06:59.262 --> 07:03.480 1日単位､ あるいは1カ月単位で行う｡ 07:03.480 --> 07:05.211 例えば､ 私はバックエンドの自動化や関数の多くにAWS 07:05.211 --> 07:11.010 Lambdaを使っているが､ 使用量に応じて課金される｡ 07:11.010 --> 07:14.760 今は100万回リクエストするごとに20セント請求される｡ 07:14.760 --> 07:20.092 だから､ オートメーションはとても効率的な方法なんだ｡ 07:20.092 --> 07:22.620 何百万､ 何千万というリクエストがあっても､ 07:22.620 --> 07:27.090 私にかかるのは数ドルだ｡ 07:27.090 --> 07:28.334 もうひとつは､ 07:28.334 --> 07:33.000 従量制と計量制の区別があることだ｡ 07:33.000 --> 07:35.640 従量制や計量制のサービスについて話すとき､ 07:35.640 --> 07:41.160 私たちは本当に同じことを話している｡ 07:41.160 --> 07:42.840 しかし､ ここには違いがある｡ 07:42.840 --> 07:44.850 従量制のサービスを利用している場合､ 07:44.850 --> 07:49.380 実際の使用量に応じて料金を支払うことになる｡ 07:49.380 --> 07:52.500 水道代や電気代について考えてみてほしい｡ 07:52.500 --> 07:55.650 今月､ 水道のホースをつけてプールに水を入れたとしたら､ 07:55.650 --> 07:59.670 水の使用量が多いので水道代が高くなる｡ 07:59.670 --> 08:02.314 逆に､ 実測サービスを利用する場合､ 08:02.314 --> 08:04.950 これは携帯電話のプランに近い｡ 08:04.950 --> 08:08.160 たいていの場所では､ 携帯電話の使用量（テキストメッセージ､ 08:08.160 --> 08:14.100 分数､ データ通信など）に対して､ 毎月一定の使用料を支払っている｡ 08:14.100 --> 08:15.390 そして､ 一旦その限度額まで行くと､ 08:15.390 --> 08:19.440 彼らはサービスを停止し､ 再度支払うまでそれ以上のサービスは受けられない｡ 08:19.440 --> 08:21.300 従って､ 量り売りサービスについて考えるときは､ 08:21.300 --> 08:23.310 ある量の料金を先払いしているという事実を考え､ 08:23.310 --> 08:27.660 それを使うかどうかにかかわらず､ すでにその分の料金を支払っているのだ｡ 08:27.660 --> 08:28.493 しかし､ 従量制のサービスであれば､ 08:28.493 --> 08:31.253 使用量に応じた料金を支払うことになる｡ 08:31.253 --> 08:33.480 クラウドを使うメリットのひとつは､ ほとんどのことが従量制で行われ､ 08:33.480 --> 08:37.883 使った分だけ料金を支払えばいいということだ｡ 08:37.883 --> 08:41.160 次にお話しするのは､ 共有リソースについてです｡ 08:41.160 --> 08:46.530 共有リソースというのは､ 仮想マシンを他人のサーバーに置くことができるため､ 08:46.530 --> 08:50.220 コストを最小限に抑えることができるということです｡ 08:50.220 --> 08:54.238 アマゾンやアジュール､ グーグル・クラウドで使っているサーバーを見ると､ 08:54.238 --> 08:56.022 良質なものでも1台1万ドル､ 08:56.022 --> 08:58.980 2万ドル､ 3万ドルする｡ 08:58.980 --> 09:00.151 ワードプレスのブログをホスティングするために､ 09:00.151 --> 09:02.640 そのうちの1つを購入する必要があるとしても､ 09:02.640 --> 09:08.100 読者が数百人しかいないのであれば､ それほど負荷はかからないだろう｡ 09:08.100 --> 09:10.020 その代わり､ 高価なサーバーを1台だけ用意し､ 09:10.020 --> 09:18.450 それを分割して仮想マシンにし､ 使いたい人全員に配る方がずっと理にかなっている｡ 09:18.450 --> 09:24.480 そのため､ 1つのサーバーで50や100のWordPressブログをホストできるかもしれない｡ 09:24.480 --> 09:26.760 それが共有リソースを使うという考え方だ｡ 09:26.760 --> 09:33.150 共有リソースというのは､ クラウド・プロバイダーのデータセンターを構成するすべてのハードウェアのことだ｡ 09:33.150 --> 09:35.215 アマゾンやグーグル､ アズールが考えているのは､ 09:35.215 --> 09:37.987 私の会社にとって需要が高い時期があれば､ 09:37.987 --> 09:48.090 あなたの会社にとっては低い時期があるかもしれないし､ その逆もあり得るということだ｡ 09:48.090 --> 09:51.480 そのため､ 各社に専用のハードウェア・リソースを用意する代わりに､ 09:51.480 --> 09:54.009 全社でリソースを共有することができる｡ 09:54.009 --> 09:55.500 そしてクラウドの最後の特徴は､ 09:55.500 --> 09:58.710 ファイル同期ができることだ｡ 09:58.710 --> 10:01.103 さて､ クラウドベースのリソースを使うことの素晴らしい点は､ 10:01.103 --> 10:02.760 ある場所に何かを置くことができ､ 10:02.760 --> 10:07.500 それをどのように設定するかによって他の場所に広げることができるということだ｡ 10:07.500 --> 10:09.420 例えば､ 私の会社では､ ファイル同期に頼ることが多い｡ 10:09.420 --> 10:11.428 というのも､ 私たちの会社の従業員のほとんどは､ 10:11.428 --> 10:17.640 オフィスだけでなく世界中で働くリモート従業員だからだ｡ 10:17.640 --> 10:20.100 このファイルを私のグラフィックデザイナーに渡して､ 10:20.100 --> 10:27.060 私が話しているときに皆さんがスクリーンで見ているようなさまざまなものを作ってもらう必要があります｡ 10:27.060 --> 10:31.320 そして彼女は､ 私のビデオ編集者がいる別の国にそれを送りに行くんだ｡ 10:31.320 --> 10:34.410 完成したら､ 私のオフィスに送り返され､ 10:34.410 --> 10:41.040 そこで私のスタッフが品質保証チェックを行う｡ 10:41.040 --> 10:43.779 だから､ この1本のビデオは､ おそらく4つか5つの異なる場所を旅して､ 10:43.779 --> 10:49.470 今スクリーンで見ているような完成品になったんだ｡ 10:49.470 --> 10:50.303 これはファイル同期のアイデアで､ 10:50.303 --> 11:05.430 私がこれを録画するとき､ クラウドベースのファイルサーバーに録画しているので､ 私のチームの全員がそのファイルにアクセスすることができます｡ 11:05.430 --> 11:08.190 録画からパブリッシング､ 11:08.190 --> 11:13.710 そして視聴までの間に必要なすべてのことが､ 11:13.710 --> 11:20.730 すべてのサーバーで非常に合理的に行われる｡ 11:20.730 --> 11:24.420 ビジネスの観点から見たクラウドの本当の大きなメリットのひとつは､ 11:24.420 --> 11:26.970 オフィスにサーバーを置かないということだ｡ 11:26.970 --> 11:28.201 現在は､ 保護され､ 11:28.201 --> 11:37.740 可用性が高く､ スケーラブルで､ 需要の増減に柔軟に対応できるデータセンターのクラウドに置かれている｡ 11:37.740 --> 11:39.015 使った分だけ支払えばいいし､ 11:39.015 --> 11:45.480 同じ物理的なサーバー上にいるのだから､ 知らない人たちともリソースを共有できる｡ 11:45.480 --> 11:50.970 クラウドの特徴や､ 世界中の多くの企業でクラウドへの大きな移行が行われている理由について話し始めると､ 11:50.970 --> 11:53.740 これらはすべて私たちが話していることなのだ｡