【企画部のためのシステム講座】クラウドとオンプレミスは、果たして何が違うのか?
- TAG : AWS | Tech & Science | クラウドサービス | マーケティング・テクノロジスト | 企画部の知るべきシステム知識
- POSTED : 2014.11.11 08:43
f t p h l
目次
「クラウド」は「オンプレ」に比べて、何が優れているのか?
近年、クラウドという言葉が良く使われています。実際、読者の皆さんも、新聞やニュースなどで、その言葉を目にしない日は無いと思います。しかし、「クラウドが登場する前」と「クラウドが登場してから」では、一体、何がどのように便利になったのか?と改めて問われると、明確に答えられる方は少ないのではないでしょうか。当記事では、そんな基本に立ち返って「クラウドの価値」を捉えなおしてみたいと思います。
いまさらですが「クラウドサービス」とは?
まず、そもそも「クラウド」とはなんでしょうか。wikipediaより引用します。
クラウドコンピューティング(英: cloud computing、または単にクラウドとも)とは、ネットワーク、特にインターネットをベースとしたコンピュータ資源の利用形態である。ユーザーは、コンピュータによる処理やデータの格納(まとめて計算資源という)をネットワーク経由で、サービスとして利用する。
名称:
「クラウド」は「雲」の意味で、コンピュータネットワーク(典型的にはインターネット)を表す。従来より「コンピュータシステムのイメージ図」ではネットワークを雲の図で表す場合が多く、それが由来となっている。出所:wikipedia
つまり、クラウド=cloud=雲 ということになりますが、その単語自体に意味があるわけでなく、ネットワークを介してコンピュータを使う(つまり、目の前にないコンピュータを使う)という利用形態を指しているわけですね。
クラウドサービスを使う、ということ
それを踏まえ、「クラウドサービス」というものを考えてみましょう。クラウド=目の前にないコンピュータをネットワークを介して使うコト、ですので、クラウドサービスは「誰かが、目の前にないコンピュータを貸してくれる」サービスと捉えていただけるとよいのではないかと思います。
つまり、クラウド業者が「今まではお客さんが自分で持っていたモノ」の代わりに、「クラウド業者が持っているいろいろなモノ」をネットワーク経由で提供する。これが「クラウドサービス」です。
具体的に言うと、AAAという会社さんが・・・
- 今まで自社基幹システムの為に、Windows Serverを使っていたけれど、これをAmazon EC2の仮想サーバ(Windows Server版)で置き換える。
※このような使われ方をするサービスを、 IaaS(アイアース:Infrastructure as a Service)と呼びます。 - 今まで自社サイトのアクセスログ分析の為に、Hadoopサーバを持っていたけれど、これをAmazon EMRで置き換える。
- Hadoop上の解析アプリケーションや解析用コマンドは今までのモノをほとんどそのまま使う。
※このような使われ方をするサービスを、 PaaS(パース:Platform as a Service)と呼びます。 - 今まで自社でメールサーバを持っていたけれど、これをgamilのサービスに乗り換える。
- 今まで自社でOutlookのサーバを持っていたけれど、これをOffice365に乗り換える。
※これらのような使われ方をするサービスを、 SaaS(サース:Software as a Service)と呼びます。
といった事をした場合、このAAA社さんは、クラウドサービスを利用していることになります。
一方、ここでいう「今まで」のように「自社でモノを持つスタイル」を「オンプレミス(on-premises:建物内/構内)」と呼びます。最近では、「クラウドで行くか?オンプレミス(オンプレ)のままで行くか?」のように、両者が対で比較されることが多くなってきました。
同じ機能を持つシステムを「クラウド」と「オンプレ」で比較してみる
ここで私が、 AAA社さんから「こんなシステムを提案して欲しい」という依頼を受けて、そのシステムを「クラウド」と「オンプレ」でそれぞれ提案する場合のシステム構成を考えてみたいと思います。題材は、「社内SNSを自社で新規システム開発する提案」としましょう。
また、必要な機能として、
- 商談などの情報をインターネットから登録して社員みんなで共有できる。
- 画像ファイルなども共有できる。
が求められたとします。
この場合、私は以下のようなシステム構成提案をします。
1.オンプレの場合
2.クラウドの場合(※クラウド業者としてAmazon Web Services(AWS)を選定したケース)
この、「オンプレミスでのシステム構成」と「クラウド(AWS)でのシステム構成」の違いについて、以下に、詳しく見ていきましょう。
①.「ファイアウォール」は「セキュリティグループ」などで置き換える
ファイアウォールはネットワーク上にいる外敵からの攻撃を防ぐ目的で設置されます。
各通信経路に対してプロトコルレベルで許可設定・拒否設定の制御を行うことが主な機能ですが、クラウド構成では、これを「セキュリティグループ」といわれている機能で置き換えます。セキュリティグループは、各クラウドサービスに対してのセキュリティ設定をクループ化して制御する機能です。例えば、仮想サーバ提供サービスである「Amazon EC2」には「EC2セキュリティグループの設定」があります。
データベース提供サービスである「Amazon RDS」にも同様に「RDSセキュリティグループの設定」があります。
仮想ストレージ提供サービスである「Amazon S3」にはアクセス制御の設定機能があり、許可された者以外からのファイルに対するアクセスを排他することが出来ます。
これらの機能は、各クラウドサービスが提供している機能の一部であるがゆえに、設定や使用による費用の追加がありません。
尚、前述の図では述べていませんが、クラウド業者以外のソフトウェア会社から「仮想ファイアウォール」という製品が提供されている場合もあります。但し、これについては、ほとんどの製品が有償ですので注意が必要です。
②.「アプリケーションサーバ」は「Amazon EC2」で置き換える
アプリケーションサーバは、業務アプリケーションを動作させる為のサーバで、いわゆる「普通のサーバ」です。クラウド構成ではこれをAWSの仮想サーバ提供サービスである「Amazon EC2」で置き換えます。そのEC2のサービスで「仮想サーバインスタンス」を作成し、作成された仮想サーバに対して業務アプリケーションのインストールを行い動作させます。
尚、WindowsやLinux等のサーバOSについては、仮想サーバインスタンス作成時にクラウドサービスから「どのOSを搭載した仮想サーバインスタンスを作成しますか?」という選択肢を与えられますので、そこで、ニーズに合わせて選択することになります。
③.「データベースサーバ」は「Amazon RDS」で置き換える。
クラウド構成ではこれをAWSの仮想サーバ提供サービスである「Amazon RDS」で置き換えます。そのRDSのサービスで「仮想DBインスタンス」を作成します。
MySQLやOracle, PostgreSQL等のデータベースソフトについですが、仮想サーバインスタンス作成時にクラウドサービスから「どのデータベースソフト上に仮想DBインスタンスを作成しますか?」と問われ、選択することになります。
尚、RDSの場合は、WindowsやLinux等のサーバOSについては、クラウド利用者がサーバOSを意識することはありません。もちろん、OSに関する選択や設定をすることもありません。
④.「画像ファイルサーバ」は「Amazon S3」で置き換える
今回想定しているシステムは、SNSのサービスで画像ファイルを取り扱う設定ですので、それを格納する画像ファイルサーバを用意する必要があります。
この画像ファイル格納サーバは、クラウド構成ではAWSの仮想ストレージ提供サービスである「Amazon S3」で置き換えます。
S3に関しても、WindowsやLinux等のサーバOSを、クラウド利用者が意識することはありません。もちろん、OSに関する選択や設定をすることもありません。
クラウド導入のメリットとは
ここで、上記のようなシステムをクラウドで提案した場合の、具体的なメリットを述べていきたいと思います。
①.初期インフラ構築スピード
今回のようなシステムを一から構築した場合、構築までには以下のような構築手順と時間を要します。
作業内容 | オンプレで構築した 場合の作業時間 |
クラウドで構築した 場合の作業時間 |
データセンタ選定 | 3日 | 0.5日 |
データセンタ選定レビュー | 1日 | 0.25日 |
機器選定 | 2日 | 0.25日 |
機器選定レビュー | 1日 | 0.25日 |
機器の発注~機器の到着待ち | 14日 | 0日 |
機器の据付 | 1日 | 0日 |
ネットワーク導通設定 | 1日 | 0日 |
インフラ構築作業 | 3日 | 0.5日 |
合計 | 26日 | 1.75日 |
こうして、改めて一つ一つの手順を追ってみると、私自身もクラウドの圧倒的なスピード感に驚かされます。
②.インフラ障害時における復旧スピード
不幸にしてサーバがダウンした場合の対応に関してもクラウド導入のメリットは大きなものがあります。
私は過去にセットアップしたデータベースサーバの電源ユニットの不具合にみまわれた事がありました。その時は以下のような普及手順と時間を要しました。
作業内容 | オンプレで構築した 場合の作業時間 |
クラウドで構築した 場合の作業時間 |
ハードウェアベンダへ連絡 | 0.2日 | 0日 |
機器の到着待ち | 1日 | 0日 |
機器の据付 | 0.6日 | 0日 |
サーバ再起動後の復旧作業 | 0.2日 | 0.2日 |
合計 | 2.0日 | 0.2日 |
ミッションクリティカルなシステムに関してはオンプレ・クラウド問わず冗長化構成を取っているでしょうから、上記のような差異は発生しないと思いますが、予算等でシングル構成を採用しているシステムはたくさんあると思います。
実際にサービスを提供されている方や、システムの運用保守を行っている方であれば、この復旧スピード速さは魅力的なのではないでしょうか?
③.マシンスペックを変更可能(=間違えてもマシンを買い直す必要が無い)
システムを構築する際、ハードウェアに関する”事前見積もり”は頭の痛い問題です。例えば・・・
- 分析要件が定まらず、データ量の予測が困難(どれくらい増加していくのか見当もつかない)
- 制御に必要なCPU性能・メモリ容量は、そもそも門外漢だからわからない
- 余裕を持ったハードウェア構成の見積もりをしてみたら、金額が予算オーバー
- ハードウェアを購入後にそのスペックが不足している…(最悪のケースはハードウェアの買い直しが発生)
これらの課題を解決する上で、クラウドサービスの導入は非常に有効な解決策と言えます。
クラウドサービス上でサーバを構築する場合、サーバが稼動する仮想マシンを作成するタイミングでマシン性能(CPU性能・メモリ容量・ストレージ容量など)を「クラウド上の設定値」として指定し、仮想サーバ作成を行います。クラウドの最大のポイントは、この設定値は「後から変更可能」ということです。
つまり、”とりあえず見積もった性能”でクラウド環境上にサーバを立ち上げて、システム環境を構築した後に「過不足」を判断すれば良いのです。試験フェーズで過不足がわかった段階で仮想マシンの「設定値」を変更して仮想マシンの再起動を行えば、スペック変更された環境でシステムを稼動できるのです。(そしてもちろん、この作業は何度でも繰り返すことができます。)
この柔軟性をオンプレ構成で実現することは非常に困難です。まさにクラウドの真骨頂ともいえるポイントでしょう。
④.初期投資を抑えられる
システムを構築する際、ハードウェアに関する”事前見積もり”は頭の痛い問題です。例えば・・・
- ハードウェア
- システムの設置場所に対する家賃
- ネットワーク敷設費用
最低でもこれらの費用を事前に予算化しなければなりません。
クラウドサービスを利用する場合、上記の費用は全て「月々のクラウドサービス利用料」という形でクラウドベンダから請求されますので、初めに大きなお金を用意する必要がありません。また、クラウドベンダによっては年間契約を結ぶことによって、さらに費用を圧縮することが可能になります。
以上、駆け足でふりかえってみましたが、あらためて本当に便利な世の中になったと感じます。我々技術者としては、この与えられた便利さを安穏と享受するのではなく、便利になった基盤上にさらに付加価値の高いサービスを構築・提供していかなければいけないと強く感じるこの頃です。
f t p h l