三大クラウド（AWS・Azure・GCP）を使いこなすマルチクラウド活用術 #1 クラウド活用成熟度
こんにちは！DATAFLUCT service platform. の開発とマルチクラウド戦略を推進している原田です。
service platform は、データの収集・蓄積・加工・活用まで企業のデータ活用をトータルでサポートするためのプラットフォームです。
今回は、データ活用やDXに欠かせない存在となったクラウドサービスを徹底的に使いこなすためのマルチクラウドをテーマに取り上げ、世の中の流れを整理しつつ、我々のプラットフォームがどのように対応していこうとしているのかを紹介する連載記事の第一弾です。
今回はマルチクラウドの具体的な内容に入る前の序章として、各社の比較とクラウド活用成熟度について触れていきます。
1. 欠かせない存在となった三大クラウド（AWS・Azure・GCP）
皆さん、クラウドサービスは何か使っていますか？
MM総研さんの2019年6月のレポートによると、AWS, Azure, GCPを利用・検討している企業がかなり増えてきているようです。
PaaS利用者/利用検討者のサービスランキング（複数回答）
IaaS利用者/利用検討者のサービスランキング（複数回答）
引用：MM総研2019年国内クラウドサービス需要動向調査（https://www.m2ri.jp/release/detail.html?id=354）
なぜ、クラウドサービスの利用が増えているのか。最大の理由は「規模の経済」にあります。AWS、Azure、GCPは毎年数千億円規模の設備投資を継続的に行っており、各社の年間のR&D費用は1.5兆円を超えています。そんな桁違いの投資によって作られた環境を非常に安く使えるのがクラウドサービスの最大のメリットです。
クラウドサービスが台頭する以前は、IT投資には数百万・数千万円掛かるのが当たり前でしたが、クラウドサービスが普及した現在は月に数万円もあれば十分な技術検証・スモールスタートができるようになりました。
結果、投資リスクが大幅に下がったことで世界中でスタートアップが増大し、大企業も思いがけない企業との競争を強いられるようになり、デジタルトランスフォーメーションが求められるように至ったわけです。
2. どのクラウドを使えばいいの？
結論から言うと、IaaS用途のみであれば「AWS・Azure・GCP」だったら正直どれでもいいです。ただし、使いたい機能がPaaS、DevOps、機械学習/AI、IoT などの領域になってくると各クラウドによってできることが異なります。
各社ともユーザーからのフィードバックを重要にしており、現在ではクラウドサービスのコアな部分に大きな差は無くなりました。（もちろん、細かい部分を比較すればいくらでも違いは見つかりますが…）
少なくとも、各サービスを机上で比較して、「よし、このクラウドに決めた！」と一択してしまうのはやめましょう。机上調査で比較した〇×表を作っても、半年も経てば改善されて状況が変わります。
DATAFLUCTとしては、「全て使いこなし、適材適所で組み合わせる」という方針でノウハウを蓄積しています。
最終的にはすべてのクラウドを使いこなして、自社のエンジニアが好きなものを組み合わせて利用できる状況になっているのが健全です。下手にガバナンスをきかせて利用可能なクラウドを絞るとシャドーITの発生要因に繋がります。
ただし、マルチクラウド環境にするとリスクも増えます。そのあたりは次回以降のNoteでまとめていきたいと思います。
個人的にこの三社で大きく違うと感じるのは以下の点です。
認証機能
・Azure / GCP は独立したID認証基盤が存在し、サブクリプション（Azure）やプロジェクト（GCP）の共通の認証先として利用
・AWSは各アカウントに共通したID認証基盤が存在しないため、自前で「このAWSアカウントを認証用に利用する」という設計をする必要がある。
リソース管理方法
・Azureは、管理グループ > サブスクリプション(請求単位) > リソースグループ > リソースという階層型の管理構造を「強制」する。適宜タグを使って管理情報を持たせる。グルーピングルールだけしっかりと考えればよいので管理しやすい。強制されるのが嫌いな人に向かない。
・AWSは、Organization > AWSアカウント(請求単位) > リソースという構造で、リソースに割り当てた「タグ」を使ってリソースグループを構成できるが、「必須ではない」。タグ付け職人がしっかりと管理しないと散らかりがちになる。
・GCPは、組織 > フォルダ > プロジェクト(請求単位) > リソースという構造で、アラート設定やポリシーなどを統一的に割り当てるためのグループ化の機能が用意されているが、「必須ではない」。
データ分析・機械学習関連
このあたりは結構違いがあります。
細かい話になるのでまた別の機会に記事化します。
AWSは自由度が高く、各サービスを「パーツ」として様々な組み合わせが可能となっており、エンジニア気質の方にはとても好まれています。反面、自前でしっかりと管理ルールを作らないと権限管理やリソースが散らかってしまうので、管理者がいないと危険です。
仮想マシンやコンテナ系はどのサービスも非常に充実しています。Kubernetesは生みの親であるGoogleが一歩進んでいますが、ここもすぐに差がなくなると思います。KubernetesはWebサービスの基盤用途だけでなく、機械学習のトレーニング・チューニング・デプロイ先としても欠かせない存在になってきたため、各社とも非常に力を入れている領域です。
開発者向けツールは、Azure DevOpsやGitHub、Visual Stuido Codeを持つMicrosoftが非常に充実しています。ただ、これらのツールはAWSやGCPからも使えるように設計されているのでマルチクラウド利用でメリットが出やすい領域です。
あと、Azureはオンプレミス連携やエッジ系に強いのも特徴です。エッジ側でIoT系やAI系の前処理をしてからクラウドサービスに蓄積したい場合にとても便利です。
各クラウドのサービス単位の比較はいろんな方がまとめていますが、最近だと以下のQiita記事がとてもよくまとまっているので合わせて参照してみてください。
・AWS/Azure/GCPサービス比較 2020.04
3. クラウド活用成熟度
クラウドサービスを使ったデジタルトランスフォーメーションの事例を目にすることも増えてきましたが、そこに至るまでのクラウドサービス活用レベルには成熟度があります。
Step1：Lift & Shift
まずはIaaSを使ってシステムを単純移行し、徐々にクラウド最適化をするやり方です。
一般的にここからスタートする企業が多く、リリース当初はIaaSに注力してきたAWSが大きな強味を発揮し、シェアを獲得しました。
逆にPaaSからスタートしたAzure、GCPは使いこなせばとても便利でしたが「システム改修しないと移行ができない」という点が障壁となり想定よりも利用者が伸びなかったという経緯もあって、急ピッチでIaaS対応しました。
このスタート地点の違いが現在のシェアの差の主な要因となりましたが、現在はIaaS領域に大きな差がなくなったので、この段階はどのクラウドサービスを選んでも特に支障はないでしょう。
スタートアップはそもそも移行するシステムがないため、この段階をスキップできるのも大企業よりもクラウド化が進んでいる理由の1つです。
Step2：Modernization（モダナイゼーション：近代化）
PaaSを有効活用し運用効率化とコスト最適化を目指すステップです。強力なPaaSを持つAzureとGCPがシェアを巻き返すきっかけにもなりました。
特にデジタルトランスフォーメーションを実現するための基盤作りとして開発の近代化を目指しDevOpsを実践する企業が増えています。
ただ、長年培ってきたウォーターフォール型の開発ノウハウやルールがしがらみとなり、仕組み作りや文化の醸成がうまくいっていない企業が多いのが実情です。
Step3：Digital Transformation（デジタルトランスフォーメーション、DX）
IoTや人工知能・AIなど各社が提供する先進技術を使ったデジタルビジネスの創出にチャレンジするステップ。一足飛びにIoTやAIにチャレンジする企業も多くいるが、モダナイゼーションが不十分だとうまくいかないケースが多いです。
いきなりDXにチャレンジしちゃダメなの？って思う方もいるでしょうが、顧客フィードバックを収集し、プロダクトに反映する仕組みがないままビジネスを作っても、高い顧客満足度は得るのは難しいでしょう。特に大企業の場合は既存ルールが足枷となることもあり、既存ルール自体の近代化も重要となってきます。
4. まとめ
連載第一弾は、クラウドサービスの実情とクラウド活用成熟度についての内容でした。マルチクラウドは各社の特長的なサービスを使いこなすことができるメリットがありますが、活用成熟度が低いまま取り組むと、各エンジニアが好き放題してしまう「カオス環境」となり収拾がつかなくなります。
失敗事例を作ってしまうと社内のクラウド活用やモダナイゼーションの反対勢力に勢いを与えかねないので、しっかりとリスクを潰しながらマルチクラウド環境を作っていきましょう。
次回、マルチクラウド環境の統合認証についてまとめたいと思いますので、興味がある方は是非DATAFLUCTをフォローしてください！
更新通知はこちらから
SNSのフォローお待ちしています！
https://twitter.com/datafluct
続編はこちらから