1. はじめに（自己紹介）

• #クラウドインフラエンジニア

筆者がクラウドに触れたのは2010年頃、クラウドという言葉が出回り始め、AWS（Amazon Web Service）も少しずつ話題になってきた時代でした。

それまでの私のキャリアは、SI会社でインフラエンジニアとして通信、製造、公共、金融の各業界で案件に携わり、開発からPMまで一通り経験してきていた、という状況でした。

クラウドを初めて経験したのは通信業の更改案件、インフラをオンプレミスからAWSへ移行するというものでした。

当時はVMWareが主流の時代であり、ＶＭ（Virtual Machine）をAWS上に移行し、仮想マシンとして移行前と同じ要件で利用するという案件。当然ですが、オンプレの感覚が身に染みついていたため、私にとってクラウドはとても新鮮でした。

今となっては各クラウドで数多のサービスが展開されており、これらを理解していこうと思うと気が滅入ってしまいますが、当時はAWSでいうEC2、S3、RDSぐらいしか利用せず、仮想マシンの延長として利用していたため、そこまでクラウドに抵抗はなく、すんなり馴染むことができました。

その後も、増えていくサービスを徐々に覚えていくことでキャッチアップをしていくことができ、手前味噌ながら、カンファレンスに登壇して話ができるまでになりました。

黎明期からクラウドに関わってきた私の知見が、みなさまのお役に少しでも立てればと思い、今回筆を執ることに致しました。

2. クラウドとは

オンプレとクラウドの違いについての説明は割愛させて頂き、ここではクラウドの種類や特徴をお伝えします。

ひとくちにクラウドといっても、プライベートクラウド、ハイブリッドクラウド、そしてパブリッククラウドと、大きく3種類のクラウドがあります。

プライベートクラウド

各社のDC（Data Center）で提供する仮想環境を提供するサービス、というのがざっくりとしたイメージです。

ハイブリッドクラウド

プライベートクラウドや自社DCとパブリッククラウドを組み合わせたハイブリッド構成、というイメージです。

パブリッククラウド

世間で主に話題になっているのはパブリッククラウドです。

メジャーなパブリッククラウドとして、Amazonが提供するAWS、Microsoftが提供するAzure、Googleが提供するGCP（Google Cloud Platform）があります。

他にもAlibaba Cloudなどもありますが、2020年現在は、AWS、Azure、GCPが3強といったところでしょうか。

各パブリッククラウドの特徴は下記のとおりです。

AWS (Amazon Web Service）

パブリッククラウドの代名詞といっても過言ではありません。
導入実績は、世界的に見てもダントツ1位です。
導入実績が多いことでナレッジも貯まっており、各社に導入する際に検討しやすいのも後押しとなり、今後も導入実績は伸びていくと考えられます。
また、利用ユーザーのリクエストに応じたサービスの機能アップデートも行われており、痒いところまで手が届くクラウドになっていると感じています。

Azure (Microsoft Azure)

なんといっても、Microsoftが提供している点が大きいです。
近年、導入実績も急速に伸びてきています。
その背景に、Windowsと連携したVDIサービスや、Microsoft365、企業には欠かせないActive Directoryとの親和性が後押しとなっています。
AWSに追従すべくサービスの機能アップデートも頻繁に行われ、どんどん使いやすくなってきています。

GCP (Google Cloud Platform)

AWS、Azureに比べるとIaaS領域では、導入実績はほとんどありません。
しかし、Googleには独自に培った技術があります。
中でも、AIやデータ分析基盤は他社にはない強みになっているのではないでしょうか。
その領域では、導入実績も多くなってきています。
コンテナ技術で有名になったKubernetesもGoogle発の技術になります。

近年は、一つのクラウドに絞るのではなく、用途に合わせてクラウドを選択する傾向が強くなってきています。

3. 従来のオンプレとクラウドの違い

オンプレとクラウドの違いはすでに語り尽くされていると思いますが、SIerのインフラエンジニアの視点から、クラウドがオンプレと比べて大きく異なるポイントを3つご紹介したいと思います。

すぐに利用可能

オンプレの場合、HWを発注して納品までは2～3カ月かかったりします。

一方で、クラウドの場合はクリックするだけでVMが用意されます。開発期間が大幅に短縮できる点が大きなメリットと言えるでしょう。

可用性、耐障害性が担保されている

オンプレの場合、HDDをRAID1で組む、RAID1+0で組む、clusterを組む、HW2台買って冗長化するなどが、可用性や耐障害性を担保するための主な手段です。

一方、クラウドの場合、クラウド側ですでに可用性等を担保する仕組みがサービスとして組み込まれており、VMをデプロイすれば冗長化されている状態が実現できます。

様々なサービスが提供されている

オンプレの場合、Webサーバを立てる際には、OSをインストールし、その上にTomcat等のWebサーバ をインストールして設定する必要がありました。

クラウドの場合、PaaSでWebサービスが用意されていますので、デプロイすれば希望する環境がすぐに使えます。このメリットは大きいです。開発コストを削減することができますから。

上記3点から判断すると、クラウドは開発期間をかなり短縮でき、コストも削減できるというイメージをお持ちになると思います。

実際のところはどうでしょうか。ウォーターフォール開発を前提に、3つの観点から見比べてみましょう。

• 開発コスト
• 開発期間
• 保守運用

折角ですので、クラウドは万能ではない、という観点で説明をさせて頂きます。

開発コスト

まず1つ目は、開発コストです。

コストには、大きく分けて、イニシャルコストとランニングコストがあります。

オンプレの場合は、イニシャルコストがかかり、ランニングコストはさほどかかりません。
クラウドの場合は、イニシャルコストはさほどかからず、ランニングコストがかかります。

この差をどうとらえるかが重要で、損益分岐点をしっかりと把握することが重要になります。

初期投資という観点では、オンプレはイニシャルコストがかかり、クラウドはイニシャルコストがかからない点から、クラウドは一見安く見えます。

しかし、落とし穴はあります。

クラウドの場合、HWを保有しないことからHW更改を気にする必要はありません。前述の通り、イニシャルコストもかかりません。

一方、オンプレの場合は一般的に、HWの保守切れが発生する5年をサイクルにシステム更改を行うことになります。5年に一度、莫大なHW購入費と入れ替えのための費用が発生し、大きなイニシャルコストが発生します。

ただ、ランニングコストを見てみると、オンプレの場合、一度購入・導入してしまうと、大規模な故障が発生しない限り、次のシステム更改までに発生するランニングコストはそこまでかからないという特徴があります。

一方、クラウドを採用した時に、リソースの設計を正しくせず、オンプレのままと同じリソースをクラウドで構築してしまうと、クラウドサービスは一般的に保守コストや運用コスト＋αが利用料金に嵩増しされているため、ランニングコストがオンプレの場合よりも膨大になります。

そうなると、オンプレの更改サイクルである5年が経たないうちに、損益分岐点を迎えてしまうことも少なくないのです。そうなった場合、クラウドの方がトータルコストが安いとは言えなくなりますよね。結果的に、オンプレのほうが安くなってしまうのです。

なお、OS、MWのサポート切れの話もありますが、OSやMWのアップグレードが必要なのはオンプレでもクラウドでも変わりません。

開発期間

2つ目は、開発期間についてです。

オンプレの場合、HWの購入手続きをしてから納品までのリードタイムがどうしても2か月程度かかってしまいます。

その点、クラウドは、VMも含めてサービスが予め用意されていますので、リードタイムがなくなり、開発期間の短縮につながるはずです。

しかし、筆者が担当してきた顧客、特に金融業界の案件では、結果的に開発期間が半年になるなどの劇的な短縮はほとんどありませんでした。

なぜでしょうか。秘密はプロジェクトの進め方の工夫にあります。

ウォーターフォール開発では要件定義からプロジェクトが始まりますが、各フェーズでの成果物チェックやフェーズ移行判定など、プロジェクトを進めるにあたっていくつかのステップを経ていく必要があります。

クラウドでも、一般的な開発手法を踏襲しますから、オンプレの場合と同様の手続きを踏んでいきます。

さて、オンプレの場合、HWの購入ののち納品までリードタイムはかかります。ただ、ウォーターフォール開発の場合、要件定義から構築に入るまでにいくつものステップをクリアしていく必要がありますので、要件定義が終わってからできるだけ早く発注をしておけば、構築フェーズに入ったときにはHWが整っているという状態を作り出すことができます。

HWの購入からものが届くまでに時間はかかるものの、段取りを工夫することで、案件がストップしてしまうことを防ぐことができます。

そして、クラウドで開発を進めた場合も、環境を構築するのは構築フェーズになりますので、クラウドのメリットである開発期間短縮、という観点でのメリットを見いだすことができなくなります。

とはいえ、この話はウォーターフォール開発を踏襲することが前提での話です。オンプレ全盛期に確立されたウォーターフォール開発はまだまだオーソドックスな開発手法であり、多くのプロジェクトでもウォーターフォール開発が採用されていますが、クラウドネイティブな開発手法を採用することで、開発期間の短縮を実現することができます。

例えばオンプレの場合、HWを入手してからでないと構築作業ができません。構築時に問題が発生した場合は大きな手戻りが発生し、開発がストップしてしまうことがあります。

クラウドの場合、要件定義やその前の段階で、PoC（Proof of Concept）として本構築の前に簡易的なシステムを構築し、評価や動作検証することが可能なため、問題を事前に潰して後工程の進捗を妨げないようにすることができます。

このように、すぐにリソースが利用でき、評価・検証・動作確認を早々に実施できることは、クラウドの大きなメリットであり、その特性をうまく利用した開発手法を採用すれば、開発期間の短縮が可能となるのです。

最近のクラウド開発においては、ウォーターフォール開発の前にPoCを行うのは比較的一般的になっている実感があります。クラウドネイティブな開発手法は他にもありますので、徐々に変わっていけばと思っています。

保守運用

3点目は、保守運用です。

オンプレの場合は、監視システムの構築、ログ集約基盤の構築など、運用周りのシステムを構築する必要がありました。

エンタープライズのお客様の場合、すでに自社で保守運用をするための基盤を用意されている場合もあり、その際は既存の基盤に連携させるだけで保守運用の環境が整いますが、そうでなければいちから運用周りのシステムを構築する必要があります。

クラウドの場合は、監視サービスやバックアップサービスなどが用意されており、利用も簡単です。サービスをデプロイすればAWS CloudWatchやAzure Monitorなどで自動的に監視できるようになっており、使い勝手も非常に良いです。

できれば、クラウドを使うならクラウドサービスで用意されたものを使うのが理想です。ただ、そう簡単に事は進まないのが現実です。

前述のエンタープライズのお客様は、自社で保守基盤を用意しているとお伝えしましたが、クラウド上にシステムを構築する場合も、自社の保守基盤へ連携させなければなりませんでした。その他のお客様でも同様で、大手のお客様ほど、クラウドで用意された運用系のサービスを利用できないというパターンがほとんどです。

そのため、ファイルはHULFTを使って送信しますし、ZabbixのAgentをクラウド上のVMにインストールして保守基盤から監視することになり、クラウドを利用しているにも関わらず、従来のオンプレと同様の運用をせざるを得なくなります。

そうなる一つの理由は、保守運用をしている部署の抵抗にあると私は見ています。既に確立されたオペレーションに変更が入り、新しい要素が入って作業手順に変化が生じると、自分たちの作業が増えてしまう、そのようなことはやりたくない、と思ってしまいます。

もともと保守運用は変化が少なく、如何に効率的に作業をしていくかが重要な業務のため、その他の業務以上に現場の抵抗はあるものと思われます。

ただ、最近はAWSやAzureの監視機能のみを使って運用するやり方も確立されてきており、オンプレはオンプレの保守基盤を利用し、クラウドの場合はクラウド上の監視サービスを使うなどの棲み分けも出来てきています。以前に比べて、現場の抵抗も徐々に和らいできているものと思われます。

折角クラウドを使うのですから、もっと各々のメリットを生かしたやり方が浸透して欲しいところですね。