- 更新日: 2020年07月10日
- 公開日: 2020年03月01日
経営者として知っておきたいクラウドプラットフォーム（AWS、Microsoft Azure、Google Cloud、Oracle Cloud、IBM Cloud）
最近CMでもよく耳にする『クラウド』。 「便利そうだけどイマイチ何ができるのかわからない」、「重要性がわからない」という方もまだまだ多いのが現状です。
今やクラウドの市場規模は日本の国家予算の180倍とも言われ、上昇基調にあります。 30年前、会社や学校にパソコンが導入し始めたのと同じように "クラウド" が急速に浸透してきているのです。
今回は "経営者" と銘打っていますが、クラウドに興味のある方、今後デジタル社会で生きていくすべての方の参考にしていただけるよう、情報をまとめました。
少し長文になりますので、興味あるところだけでもお読みいただければ幸いです。
クラウド市場予測のデータ： Gartner、 パソコンの市場予測データ： GRAND VIEW RESEARCH
経営者として知っておきたいクラウドプラットフォーム（AWS、Microsoft Azure、Google Cloud、Oracle Cloud、IBM Cloud）
クラウドプラットフォームについて学ぶ必要性（自己、損失、責任、収益化など）
まずクラウドを 知る・学ぶ 必要性からご紹介させて頂きます。
一般的に会社や組織、ご家庭においても、クラウドをはじめとする多くのデジタル案件を一手に引き受ける "IT担当者" という肩書の方がいらっしゃるのではないでしょうか？
そうした IT担当者が情報を集めて整理し、運用に向けて決済を進め、最終的な承認をする権限者にまで案件が来るという仕組みになっている組織は多いと思われます。 権限者は自分の経験からおおよそのリスクなどを判断して承認することになりますが、「クラウドはあまり詳しくないけれど、これで大丈夫なのかな...」「 IT担当者がまとめた情報だから大丈夫だろう...」 と何だかモヤモヤしながら承認している方も少なくないのでは。
ご自身が経験したことのある世界であれば、情報を的確に捉え、そこに潜む リスクや期待、希望までイメージできますよね。今回の記事ではクラウドについてもそんなイメージを抱けるように解説していきます。モヤモヤ感を払拭できれば幸いです。
ただ、クラウドを学習する目的がモヤモヤ感の払拭だとしても、場合によっては "損失責任" を果たすための学習をしないといけなくなるケースもあります。2018年のサイバーセキュリティー担当大臣が 「パソコンを使ったことはない」 と失言して話題になりましたが、 承認をする以上ある程度の基礎知識は知っておきたいですよね。
クラウドによる損失リスクを把握
クラウドを利用する場合と利用しない場合の "関係性" を可視化。オンプレミスとクラウドの場合では、サーバー障害発生時の立ち回りが異なる。
クラウド環境の損失ケース①： レストランの決済アプリで
| いつ | 2018年7月から11月 |
| どこで | レストランの決済アプリ「PayMyTab」上で |
| だれが損失した？ | アプリ利用者とレストラン |
| 何を損失した？ | 顧客情報（名前、メール、電話番号、注文内容、クレジットカード下4桁など） |
| なぜ起きた？ | 利用者側のAWS管理画面セキュリティー設定ミス |
| どのように起きた？ | サイバーセキュリティー研究者によって、セキュリティーホール発見 |
レストラン決済アプリ： PayMyTab のクラウド環境設定ミスによって、アプリの利用者である "お店" と "顧客" の両方に損失が。 アプリのデータは AWS に接続されていますが、 AWS に責任はなく、 アプリ運営企業や ユーザーに責任が発生。この事案の損失額は明らかではありませんが、多くのユーザーから信頼を失い、ユーザー数もしくは利用回数を低下させたことは容易に予測できます。
AWSの設定ミスによる顧客情報流出ニュース： ZDNet
クラウド環境の損失ケース②： AWSによる損失
| いつ | 2019年8月23日 |
| どこで | 200程の Webサービスやアプリ |
| だれが損失した？ | AWS利用企業もしくはAWS利用ユーザー |
| 何を損失した？ | 通信（アクセス） |
| なぜ起きた？ | AWSサーバーのオーバーヒート |
| どのように起きた？ | アクセス障害の検知にて |
2019年 8月に東京で発生した AWS の大規模障害。 データベースの復旧には 9時間半かかり、多くのアプリ利用者、アプリ運営社に被害が発生しました。この AWS の障害における利用各社の被害額は明確ではありませんが、試しに ユニクロ で試算してみると 約 9億円（国内年間売上高*を時間あたりに換算し、試算した単純結果）。その他のアプリやサービスも含めると相当な被害額であることが確認できます。
尚、こうした AWS による障害発生においても利用規約において 「AWS は責任を負わない」 と規定しています。つまり AWS を利用する企業の方でリスクヘッジする必要が。ユニクロのような EC サービスでは AWS の復旧を待つしかない、かもしれませんが、エンドユーザー向けのサービスでは、利用規約に通信障害における免責事項を記載、法的にはリスククリアしています。
AWSに限らず他のクラウドプラットフォーマーも基本的には 「クラウド環境における障害発生での責任は負わない」 としていますね。
少し古いですが、クラウドプラットフォーム側の障害でユーザーに迷惑をかけても、アプリ提供企業がユーザーに謝らないといけない事例の参考画像。
クラウドプラットフォームの巨匠 AWS がリリースされてから、 もうすぐ 14年になります。その間の経験を元に、クラウドに潜むリスクとメリットを確認しておく必要がありますね。
クラウドによる収益化
今後もデータは増える予測のグラフ。 source: statista
"クラウド" というと一般的に私達は利用する立場ですが、使い方によっては "資産"、つまりクラウドから お金 を産むこともできます。それは "データの売却" です。 2019年リクルート社が 「内定辞退率の予測データ」 を売りましたが、データは "売れる" "富を産む" 時代に入っています。もちろん法律や利用規約など色々なことが関係してきますが、最近のデータ・ビジネスをまとめると以下のようになります。
- Sky Perfect（衛星放送）： ユーザーの視聴履歴等を外部と共有
- J.Score（消費者記入）： 個人スコアを外部に提供
- ツタヤ（レンタルビデオ）： 利用履歴を提携先と共有*
- 富士通と電通： ユーザーの空き予定を把握し、イベント等を配信
- PayPay（電子決済）： 共同利用先とデータ共有*
この他にもデータから収益を産もうとする動きはたくさんあり、巷では "情報銀行" と言われるものも設立中*。従来銀行というとお金を取り扱ってきましたが、今後は "データ" 扱う時代に。 また海外では "データ" の取引を行う Web サービスも運用されていますね。
少し前までは "個人情報流出" という形で個人データが売られていましたが、最近は合法的に他社利用ありきでサービスを使うのが前提となりつつあり、本業から得られるデータを "資産化" する動きが積極的になっています。
データは扱いやすくなっている
CodeCampのログイン画面。 SNSログインを実行することで「氏名」「メールアドレス」「プロフィール写真」が自動的に CodeCamp のデータベースに入ります。
従来は個人データというと、名前やメールアドレス等を記入してもらって情報収集していましたが、今は 「Facebookでログイン」 「Googleでログイン」 と SNS アカウントで "ユーザー登録" してもらうことで情報を入手することができます。
そしてログインの基盤となる Webページや アプリ も一昔前に比べるとサンプル数も多くなっていて、 WordPress という無料のサイトビルダーで比較的簡単に Webページおよび ログインシステム を装備できるようになっています。つまり少しの開発時間と運営コストがあれば、誰でもデータ活用ができる時代になったのです。
"データ ＝ エクセル" と連想される方も多いと思いますが、データ量が増えるとエクセルは扱いにくくなり、 Web や アプリから得られるデータは一般的に "データベース" に保存されます。 "データベース" というと特別感がありますが、 phpMyAdmin （無料）などの管理ソフトを使えば低い学習コストでデータを運用することが可能です（下図参照）。
また Web や アプリ といったデジタル社会から得られるデータ以外に、 センサーや AI からデータを得るという方法も考えられるでしょう。例えば AI の顔認証技術を使って、来場者数や性別を自動的に認識させたりもできます（下図参照）。
source: Microsoft Face API
日常の業務から得られるデータはないか、一度検討してみると面白いかもしれませんね。
（小まとめ）クラウドプラットフォームについて学ぶ必要性
「クラウドのリスク」「クラウドからの収益化」「データの操作性」からクラウドを学習するモチベーションを確認しました。しかし、ここまで読んでくると 「別にクラウドに頼らなくてもいいんじゃない？」 と思われる方もいらっしゃるかもしれませんね。念の為、クラウドを利用するメリットを確認しておきましょう。
【クラウド環境を利用するメリット】
- 物理的なサーバーを用意（調達）しなくてもいい
- マシンのサイズが物足りなくなったら、 "クリック" で拡張できる（スケーラビリティ）
- データ共有が容易で、セキュア
- AI や メールサービス なども利用できる*
- とにかくコスト削減になる
【オンプレミスからクラウドに移行した企業の例】
- DeNA
- 近畿大学
- 日本経済新聞社
- シャルレ（衣料品販売）* など
現在は大手企業へのクラウド導入実績が確認できますが、デジタルマーケット全体でみても "クラウド化" 進んでいます。
- 72% の企業がなんだかのクラウド環境を導入済み
- オンプレミスは 2020年までに全体の 27% に縮小
source: Cloud Adoption Statistics for 2019 - Hosting Tribunal
クラウドの情報セキュリティ
"クラウド" のモチベーションを確認しましたが、「大事なデータをクラウド上で管理するのは危険じゃないの？」 と思われる方もいらっしゃるかもしれません。基本的に AWS、 Microsoft、 Google、 IBM、 Oracle どのメジャークラウド・プラットフォーマーを確認しても 「GDPR」 という個人データ保護のルールに準拠しています。
クラウド上のデータのプライバシーは保護されていますので、私達が利用するクラウド上の仮想マシンやデータベースには、基本的に利用者である私達しかアクセスできません。
こうしたセキュリティを管理する方法として一般的に「パスワード」が用いられますが、その他に「権限設定」でもアクセスを制御することができます。クラウド上で利用する 仮想マシン には、権限設定が設けられて、基本的にユーザーしかアクセスできない権限になっています。試しに以下の同じ内容のデータを記録する 2つのファイルにアクセスしてみてください。
下記 URL に保存されているデータファイル
https://pythonchannel.com/media/codecamp/201901/not_secret.txt
https://pythonchannel.com/media/codecamp/201901/secret.txt
上の not_secret.txt にはアクセスして TTT が表示されているのが確認できる一方で、下の secret.txt は 403エラーに。これはファイルの中身は同じであるのに、 権限 を下記のように変えているため。
Linux や サーバー関係を触ったことのある方なら分かることですが、権限（パーミッション）を変えることでアクセス制限ができます。こうした技術を活用してクラウド上の仮想マシンやデータを保護しているということですね。なので、クラウドがローカルよりも情報漏えいリスクが高いということはありません。ローカル環境でもクラウド環境でもデータ管理リスクは一定レベルで存在するものです。
【セキュアなクラウドを活かした事例】
【クラウドアプリとクラウドプラットフォーム】
Googleドライブや DropBox、 Yahoo!Box などでデータ保存、データ共有しているから AWS とかはいらない、という方もいますよね。
Googleドライブや DropBox なども確かにクラウドサービスですが、 基本的には "保存" するだけです。
今回ご紹介している "クラウド・プラットフォーム" は、 "保存" 以外に "プログラム処理" や "AI処理" などコンピューティング的な処理を実行することができます。
つまり Web や アプリ、 センサーから得られるデータを 保存・加工・統計・予測 することができるということです。
Googleドライブや DropBox などではこうした機能を果たすことはできません。
こうした同じクラウドでも役割が違うために Iaas や Paas、 Saas といった用語で区別しています。
I・P・S で各セクションの機能レベルを覚えておくと、打ち合わせ等がスムーズにいくと思いますよ。
Iaas ・・・ Infrastructure as a Service、 コンピュータの設定やアプリ開発できる柔軟度の高いレベル
Paas ・・・ Platform as a Service、 アプリ開発可能なレベル
Saas ・・・ Software as a Service、 データ保存レベル
クラウドを検討すべき企業や団体とクラウド開発にかかる費用
ここまでいくつかのセクションでクラウドを実際に導入している企業をご紹介してきました。仮に今クラウドを導入していなくて、自社がクラウドを導入すべきかどうか、という判断ポイントを以下にご紹介します。 1つでも当てはまれば 要検討 ですね。
- 店舗や作業スペースが 2つ以上ある
- 既に Web や アプリ を運営している
- データをもっと活用したい
- 単純作業は AI で解決したい
- トレーサビリティなどをデータ管理したい
- LINEを活かしたマーケティングを展開したい
よくあるパターンが Webサイトはレンタルサーバー、売上管理は Googleシート、日報はメール、顧客管理はエクセル といった個別対応。これ クラウド（アプリ） で一元管理できたら煩雑な作業時間、大幅に減らせると思います。面倒な時間を短縮化できると同時に、スタッフのモチベーション維持にもつながるでしょう。
そして多くの方が気になるポイントに、クラウド導入・運営にかかる "予算" が上げられると思います。予算の内訳としては以下のように大分類されるでしょう。
- 導入検討コスト
- 開発コスト
- 導入後の運営コスト
運営コストについては、 AWS に直接支払うパターンとパートナー企業に支払うパターンがあります。実際にかかる費用についてですが、 「コスト削減になる」と言われているものの、コストに関する情報量は少ないです。
パートナー企業のコスト事例をみると、
それからアメリカでの運用コスト事例になりますが、
- 1000人以上の会社でクラウド運営に年間 350万ドル支出、 それよりお小さい会社で年平均 89万ドル*
この価格を見て、 高いと思われた方も少なくないでしょう。しかし、それでもクラウドが浸透して来ているということは、 多くの企業がIT や クラウド に掛ける予算を重視していると言えます。グローバルな平均値では、企業収益の 3.28% が IT の予算に充てられているそうです。もちろん業種で予算率は違い、高いもので 銀行・証券の 7%、 低いもので建設業の 1.5%となっています。
source: Deloitte
今後の企業活動を考えると、適切な IT 投資は必要になって来るかもしれません。
クラウド・プラットフォームにかかる必要は、サーバーを動かした時間で換算されます。
ハイスペックなサーバーをセレクトすれば高額になりますが、自分でそれと同じぐらいの機器を揃えることを考えると割安、という訳です。
AWS、 Google、 Microsoft、 Oracle、 IBM 各社とも 従量課金 という方式で、使った分だけの請求という方法が取られています。
クラウドプラットフォームの選び方（比較）
クラウドの導入は、 Webページやアプリの開発と違って、イニシャルコスト以外のランニングコストが高めです。 「クラウドには魅力を感じるが、できるだけ安く導入して運営できないか」 と考えられる方もいらっしゃるでしょう。
実際に AWS や Google Cloud、 Microsoft Azure など使ってみると分かるのですが、 "目には見えないコスパ"というものがあります。例えばOracle Cloud は操作画面がサクサク動くが、 Microsoft Azure は反応が遅い、といった問題です。
感覚的なものにはなりますが、コストパフォーマンスの最適化には、担当者の IT スキルとクラウド環境がマッチしているかが重要だと考えられます。例えば下図のように Microsoft Azure と Oracle Cloud では管理画面の様子が違います。
|
|
| 説明充実の Microsoft Azure 管理画面 | 必要最低限の説明しかない Oracle Cloud |
Windows と一緒で、 Microsoft のクラウド環境は説明が丁寧で、至れり尽くせりです。逆に Java や MySQL を提供する Oracle 社はすごくシンプル。 IT担当者のレベルが高ければどちらを使っても生産性に問題はないと思いますが、 IT担当者のレベルが低くて Oracle Cloud や IBM Cloud を使うと生産性が落ちると予測されます。
時間あたりの費用やサービス環境も大事かもしれませんが、プラットフォームそのものが自分たちに合っているか確認することも大事でしょう。ちなみに AWS も Google も Microsoft も Oracle も IBM も東京にサーバー拠点（リージョン）を持っていますので、国内においては速度的なものはあまり変わりません。
| 通信接続(ms) | GDPR | CLI | 個人レベルでの利用 | 対象ユーザー | 有償サポート | |
|---|---|---|---|---|---|---|
| Google Compute EngineAsia-northeast1 | 8 | ○ | ○ | ○ | エンジニア | ○ |
| Oracle Cloud ComputeAp-tokyo-1 | 9 | ○ | ○ | ○ | エンジニア | パートナー企業向け |
| IBM Cloud ComputeTok | 9 | ○ | ○ | ❌ | エンジニア | ○ |
| Microsoft Azure Virtual MachinesJapan-east | 10 | ○ | ○ | ○ | エンジニア・一般 | ○ |
| Amazon EC2ap-northeast-1 | 12 | ○ | ○ | ○ | エンジニア・一般 | ○ |
各プラットフォームでスピードテストした結果*
「ウチは業者（AWSパートナー等）に丸投げするから、操作性や生産性は関係ない」 と思われるかもしれませんが、少しでも安く運営したいと考えるなら少しは開発や管理に関与する必要があるでしょう。
AWS や Microsoft などでは、クラウド環境の有償サポートプランも用意されていますので、自社でも対応できるか検討してみると予算削減に繋がるかもしれません（下図参照）。
Microsoft サポートプラン*
具体的なクラウドプラットフォームの選び方としては、
- クラウドを利用する目的
- 関与する技術者レベル
この 2点で決まってくると思います。実績重視で採用を決めがちだと思いますが、 Oracle Cloud ならではの良さ、 Google ならではの良さというのもありますので、短絡的に "ブランド力" だけで決めないように注意しましょう。概ね、導入事例から自社のクラウドにはどこがいいか選定できると思います。
実際に使ってみる
- 所要時間 20分
- 公式ドキュメント
AWSの無料利用枠でクラウド・マシーンを起動する様子。
3分で 1CPU、 1GB の Linux マシーンが手に入ります。
「なんで IT担当でも開発者でもない経営層がクラウドを使わないといけないの？ 」と思われるかもしれませんが、クラウドを確実に理解するには実際に使ってみるのが一番です。
今回はクラウド・プラットフォームの中でも一番有名な AWS を使って、仮想マシンを起動してみます。恐らくはじめて パソコン を触った時のよう感覚を味わうと思いますが、確実にクラウドをイメージできるようになるでしょう。
まずは AWS の公式ページ（ https://aws.amazon.com/jp/ ）にアクセスして、アカウントを作成（下図参照）。
アカウント作成後、ログインすると以下のような画面が表示されると思います。
今回は "仮想マシン" を作るので、左下の 「仮想マシンを起動する」 をクリック。
仮想マシン ・・・ AWS上で作成されるコンピューターです。 Windows や Linux などの OS を搭載し、手元のパソコンと同じようにネットにつなげたり、プログラム処理できるようになります。
OS を選択する画面、今回は一番上の Amazon Linux 2 を選びますが、 WordPress など一定のソフトウェアを搭載したイメージも選択することができます。
仮想マシンのスペックを決めます。今回は "無料利用" なので、 タイプ： t2.micro ですが、 マシンの種類は 130種類以上用意されています、スゴイラインナップです。 「確認と作成」 ボタンを押します。
作成するインスタンス（仮想マシン）の内容を確認して、「起動」ボタンをクリック。
自分のパソコンと AWS で作ったインスタンス（仮想マシン）を接続するために "キー" を作ります。 "キー" の物体が見えないので慣れない感じがするかもしれませんが、ドアノブのキー（鍵） と意味は一緒です。上側の選択を 「新しいキーペアの作成」 にして、キーペア名を適当に入力し、 「キーペアのダウンロード」 をクリック。すると 〇〇.pem というファイル形式の "キー" が自分のパソコンにダウンロードされます。 "キー" のダウンロードが確認できたら 「インスタンスの作成」 ボタンをクリック。
すると "インスタンスは現在作成中です" と表示。画面右下の 「インスタンスの表示」 をクリック。
すると自分が作成したインスタンス（仮想マシン）の様子を確認できます。上図のようにインスタンスの状態が "running" になっていればインスタンスが動いています。そしてこのインスタンスを操作しようと思うと、コマンド処理を行って、自分のパソコンと "インスタンス" を接続する必要が。上図右下に書かれている "IPv4 パブリック IP" を使います。
今回はインスタンスの作業画面がコマンドのみですが、 Windowsサーバーや Linux Desktop ソフト をインストールすれば普段使っているパソコンと同じようにインスタンスを操作できます。
インスタンスと自分のパソコンを接続しようと思うと、上図のようにインスタンスにアクセスして、 "キー" を使ってインスタンスにアクセスする必要があります。この作業をコマンドで書くと以下のようになります。
ssh -i '/home/oshimamasara/.ssh/AWS_test_key.pem' ec2-user@18.222.178.8
ssh -i 'キーファイルの絶対パス' ec2-user@IPアドレス
ただし、上記コマンド実行前にダウンロードしていた "キー（〇〇.pem）" を、ホームディレクトリの .ssh ディレクトリに保存しておきましょう。そして キーファイルの権限を 400 に。 400は、ファイル所有者のみアクセス可能という厳しい権限の設定です。
【キーファイルの権限を変更するコマンド】
chmod 400 AWS_test_key.pem
インスタンス（仮想マシン）にアクセスできたらコマンド画面の表示が変わります。今までは左にユーザー名が表示されていましたが、 ec2-user@IPアドレス $ に変わりました。ココからは AWS のインスタンスの操作に。ちょっと不思議な感じがするかもしれないですが、いわゆる "リモート操作" ですね。試しに pwd や le と入力してみましょう。
pwd ：現在の作業ディレクトリ、 ls ：ディレクトリ内のファイルやフォルダ
Windows の場合は、 PowerShell のご利用をおすすめします。
AWSのインスタンスのスペックを確認する様子。 メモリー 1GB、 ハードディスク 8GB であることが確認できます。
あとはこのインスタンスに接続した状態で Python プログラムを実行したり、サーバー（ApatchやNGINEX）をインストールして Web アプリとして利用します。また データベースと連携させるとアプリから発生するデータを保存可能になります。
インスタンス作成後、無料利用枠のリミットが近づくと上記のようにメールが届きます。延長利用しない場合は、データ整理をして、インスタンスを削除しておきましょう。仮に無料利用枠のリミットが過ぎても、有料プランに承諾していない限り課金は発生しません。
＼Webサイト担当者としてのスキルが身に付く／
まとめ
日本は IT 後進国だと言われていますが貴社はどうでしょうか？ 日本を代表する IT企業 「NTT Data」 や 「富士通」 といった会社も AWS のパートナーとなっています*。 データ活用で勝組となった Google や Facebook を見ても、豊かな富を生み出す近道は データにあると言えそうです。
価値あるデータが手元にあっても、それを活用するためにはプログラミング技術やITリテラシーが必要になります。料理を作るには材料だけでなく道具が必要なのと同じですね。
「 ITをもっと活用したいけれど、何をどうしたらいいか分からない...」 そんな方のためにCodeCAmpではプログラミングレッスンだけでなく、 IT 全般の知識を学習できる 「テクノロジーリテラシー 速習コース」 を展開中です。
IT やプログラミングの教育を受けてこなかった現役世代が、 10年後 20年後も活躍し続けるには、自分自身のアップデートが必要かもしれません。 まずはお気軽に、無料体験レッスンでプログラミングに触れてみてはいかがでしょうか？
昨今のプログラミング・ニーズの高まりを受けて、無料体験枠が埋まっている日もあります。予め、ご了承ください。
P.S.
2019年の AWS 大規模障害を受けて、「オンプレミスとクラウド」 とか 「クラウド 2つ」 といった運用パターンが注目されつつあります。先駆者の経験を重ねた苦労、参考にしないともったいないですね。
- この記事を書いた人
- オシママサラ
