資料公開｜なぜ多くの企業がクラウドの導入・活用推進に苦戦するのか？　注意点と対策を解説

2024年7月30日にオンラインセミナー『なぜ多くの企業がクラウドの導入・活用推進に苦戦するのか？　注意点と対策を解説』を開催いたしました。
この記事では当日用いた資料を公開し、そのポイントを解説しています。

動画で見る

クラウドが難しいのはなぜか

クラウドについて触れる前に、従来のオンプレミスの構成について簡単におさらいしておきます。

上図は、オンプレミスの構成を簡略化して表した図です。Web三層構成といわれるアーキテクチャで、Webサーバー・APサーバー（アプリケーションサーバー）・DBサーバーの三層で構成されています。
用意するサーバーは基本的に同一のものですが、WebサーバーにはWeb系の資源が、APサーバーにはビシネスロジックが、DBサーバーにはデータベースが入っているというふうに、それぞれのサーバー内に入っているものが異なるという状態になっています。
また、実際にはこの他にも監視を行うサーバーや、バッチを実行するサーバーなど様々なサーバーが登場しますが、ごく簡単に図式化すると上図のような形になります。
これが、従来のインフラ構成の考え方です。

クラウド時代のアーキテクチャ

では、クラウドでのアーキテクチャの考え方はどうなるでしょうか。例えば、下図のような形になります。

こちらは、AWS Lambdaというサービスを駆使したサーバレス構成です。オンプレミスの構成と比較すると、多少複雑に見えるかもしれません。
AWS Lambdaを連続的に呼び出していき、処理をリレーしていくというような形になっており、キューを使って非同期の処理を入れるといったことも行っています。データベースは、Amazon DynamoDBというAWS Lambdaと相性のいいものを使用しています。
画面右側にあるAmazon S3というサービスを使い、データをストアしていく仕組みにしています。

オンプレミスのWeb三層構成のような考え方とは違い、適切なサービスを選定することに加え、それをどう配置し、どうつなぎ合わせていくか、またデータを持つ部分はどこかといったことまでを考えていくことが求められます。

このように、クラウドに最適化したアーキテクチャ設計は、従来のサーバー単位で考える構成とは大きく異なります。より細かい単位で機能が分割できるため、サーバー１台でなんでもやる、という考え方からは脱却する必要があります。このような点が、クラウドの難しさにつながっていると考えられます。

クラウドの良さを理解する

前項ではクラウドの難しさについてご説明してきましたが、ここからはクラウドの良さについて考えていきます。クラウドの良さとして、以下のような点が挙げられます。

クラウドの良さ

• 変更に対する柔軟性・拡張の容易性
  物理的なサーバーに依存しないため変更・拡張が容易
• 運用の低コスト化
  物理サーバーの管理からの解放、OSレベルのメンテナンスの削減などによる運用コストの低減
• 多種多様なサービス利用による実装負荷軽減
  キューによる非同期処理、通知やデータ同期、自動デプロイなど自分達で一から作るのは難しいものが活用可能

なぜクラウドを使うのか明確にする

このようなクラウドの良さを踏まえ、なぜクラウドを使うのかについても明確にしていく必要があります。
はじめに、クラウドにどんなメリットを期待するかを明確にしましょう。なんとなく良さそうだから・安そうだから・便利そうだからといった漠然として理由でクラウドを導入すると、クラウドの特性を活かした最適な構成が組みにくく、メリットを最大限享受できないことが多くなってしまうからです。
また、漠然としたクラウド導入への期待としてよく挙げられる「サーバーコストの低下」は叶わないことも多くあります。クラウドを最大限活用すると使用料が高くなる傾向にあるためです。先にお伝えしたクラウドの良さで「運用コストの低減」を挙げた通り、クラウドを最大限活用することで運用コストを下げることは可能ですが、インフラコストの低下は必ず叶うものではないため注意が必要です。

クラウド利用に適しているシステム

様々な制約でクラウド上に置くことができないシステムもないわけではありませんが、クラウドに置くことに向いていないシステムは今やほとんど存在しないと考えてよいといえます。一方で、クラウドに移行するメリットを感じにくいシステムというものは存在します。古いシステムを改修せずにAmazon EC2にそのまま移行する、というようなケースがこれに当たります。多様なマネージドサービスを使えることがクラウドの魅力のため、サーバーとしてクラウドを使うというだけでは、クラウドの良さを活かしきれていないためです。
先の例でいうと、古いシステムをそのままAmazon EC2に移行するのではなく、実行基盤をコンテナにしてAmazon ECSに載せるというふうにクラウドに合った形に変更していくのであれば、クラウド化の恩恵をより多く得られます。
それでは、新規システムはどうでしょうか。新規システムはクラウドに合わせて設計できるため、メリットを享受しやすくなっています。

クラウドの良さを活かすアーキテクチャとは？

アーキテクチャとは、「どの要素をどのように組み合わせてシステムを構築するかを決めたもの」です。
クラウドにおいては、どのサービスを使うかという「サービス選定」と、その「組み合わせ方」を指すものと考えてください。いわゆるインフラ構成図に近いものです。

このアーキテクチャ（＝どのサービスをどう組み合わせるか）を考えて、クラウドのメリットを引き出していくことになるのですが、残念ながらアーキテクチャに正解というものはありません。これは、システムによって条件が異なるため、最適なアーキテクチャというものが常に異なってくるということです。
ただし、アーキテクチャのベストプラクティスというものはあります。AWSの公式サイトや、当サイトにもいくつか掲載されているように、インターネット上に多くの情報がありますので、まずは参照してみましょう。

先述した通り、システムの要求機能や自社の制約事項等によって、最適なアーキテクチャは異なります。このため、試行錯誤しながらアーキテクチャを決定していく必要があります。アーキテクチャに正解はないが、ベストプラクティスはあるというのは、こういった理由によるものです。

クラウドの特性を活かしたアーキテクチャの例

ここからは、具体的なアーキテクチャを見ていきましょう。

こちらは、NCDCがご支援させていただいたライフネット生命様の事例で使用したアーキテクチャを簡素化したものです。ウェブアプリケーションのフロントエンドの基盤をクラウド化により一新した事例になります。事例の詳細はこちらからご覧ください。

この事例で特徴的なのは、以下の二点です。

• AWS Lambdaを用いてマイクロサービスをサーバレスで実装
• AWSのサービスを使うことでCI/CDのフローで自動デプロイを実現

また、認証をAmazon Cognitoで行う、Amazon CloudFont・Amazon S3でSPAを配置してルーティングする、AWS LamdaとAmazon DynamoDBの組み合わせでAPIの処理を行なうなど、非常によく使われるベストプラクティスに準じたアーキテクトが使われています。

もう一つ、アーキテクチャの事例を見ていきましょう。

これは、以下のような特徴を持った、IoT機器からメッセージを受信して毎日処理する、というシステムを作った際のアーキテクチャになります。

1. Amazon Kinesisシリーズの活用で、データロストなし・オートスケールが可能
2. 生データと業務に必要なデータ処理を分離
3. アプリ側はリードレプリカで負荷を分散
4. 分析側はAmazon Redshiftで集計を最適化

ここではAmazon Kinesisというサービスを利用しています。Amazon Kinesisはストリーミングサービスと言ってもいいですし、大きなキューと捉えてもいいのですが、大量に受け取ったメッセージを一つずつ後続のアプリケーションに流していくというようなサービスです。オンプレミスの時代にはなかったものですから、こういったサービスが本当に使えるのか、使うとしてどういう組み合わせだとうまくいくのか、などを考えながらシステムを組んでいく必要があります。メリットやデメリット、特性を十分に理解した上で構成を考えるということです。

本件のような構成になってくると、ベストプラクティスとして参照可能な事例も少なくなってきますが、一方で、難易度が上がった分、享受できるメリットも大きくなります。Amazon Kinesisのように取りこぼしなく大容量のメッセージを後続のアプリケーションに送るような機能は、自前で作ろうとすると大変な労力がかかってしまいますが、AWSではサービスとして提供されているため、サービスを選定し使用するだけでこれが実現可能になっているのです。
このように、様々なサービスを活用していくということが、クラウドのメリットを活かす上で大きなポイントになってきます。

クラウドサービスの選定が難しい理由

先に、クラウドのメリットを引き出すためにはアーキテクチャ（＝どのサービスをどう組み合わせるか）が重要であると説明しましたが、サービスの選択肢が数多くあることはクラウドのメリットであり、難しさでもあります。
例えばAWSの場合、2024年現在300を超えるサービスが利用できます。

もちろん300ものサービスを全て理解する必要はなく、AWS上で一般的なwebシステムを作る場合、下記のサービスを把握できていれば何とかなるでしょう。

もし最小の構成を考えるだけであれば、ここまでのサービスを把握しておく必要もありません。
しかし、複数の選択肢から最適な構成を決めたり、CI/CDを取り入れたりと、クラウドのメリット活かす方法を考えていくためには、これらのサービスの知識が必要になってきます。
更に、よりクラウドの特徴を活かしたシステムを作る場合、バッチ、非同期処理、IoT、ストリーミング、生成AI、ビッグデータなど特定の領域のサービスの知識も必要になります。

このように、数多くのサービスの中から最適だと思われるものを選んで組み合わせ行くことは困難です。サービスの「量」が、クラウドサービスの選定を難しくしている＝クラウド導入の障壁になっている一つの理由と言えます。

クラウド化を困難にする「自社の事情」

クラウド導入を困難にしているもう一つの理由として、自社に存在するさまざまな制約が挙げられます。皆さんが自社でクラウドシステムを作るに当たり、セキュリティルールや構築ルールのようなものが標準化されている場合が多いかのではないでしょうか。この標準化が最適なクラウドの活用を妨げる制約になる場合も多いです。
代表的なものとして、以下のような制約が考えられます。

• セキュリテイによる制約
  −データはすべて日本になければならない
  −（たとえ暗号化されていても）インターネットを通ってはならない
• 会社のルールによる制約
  −すでに用意されている自社ネットワーク上に構築しなければならない
  −特定のサービスは使用不可
  −開発者が自由にクラウドサービスに触れない
• 非機能要件による制約
  −バックアップを複数持つ必要がある
  −処理は何秒以内に返す必要がある・何分以内に終える必要がある
• コストの問題

このように、様々な制約がある中で、これらをクリアしながら、先ほど挙げたような数多くのサービスを選定し、組み合わせてアーキテクチャを作っていくということは容易ではありません。

クラウド活用に合わせて変わっていく組織のあり方

クラウドの利活用に、組織のルールが追いついていない場合が多く見られます。クラウド導入を少しでも簡単にするために、組織が柔軟に変化していくことも必要です。

具体的には、試行錯誤が必要なため開発者がクラウドに触ることが多いにも関わらず、開発者にその権限を渡す仕組みができていないということや、厳しすぎるセキュリティルールやネットワークルールのために、大きな制約ができてしまうということなどが挙げられます。
ルールの見直しは簡単なことではありませんが、クラウド導入を見据えて改善ができると、格段に利活用が進めやすくなります。
権限の付与やセキュリティ・ネットワークルールなど組織のルールについて、どこがネックになるかはプロジェクト次第であることが多いです。このため、プロジェクトメンバーが都度ルールを作る側と話し合えるのが最も理想的と言えます。
企業側が、実態に即して「ルールは変えていくもの」という意識を持つことが必要です。

クラウド化を上手く進めるための２つの方法

ここまでのご説明を踏まえて、クラウド化を上手く進めるための方法を以下の２点にまとめました。

1. 知見を持った専門家に頼る
   先にご紹介したような膨大な数のサービスや、様々な制約のことを念頭に置くと、知見のない企業様が一からクラウド化の推進を進めていくのはハードルが高いため、最初のうちは知見を持った専門家に頼ることがおすすめです。
2. トライアンドエラーを繰り返す
   クラウド化を進めるに当たり、ドキュメント等を調べて設計したものが、実際に使ってみようとすると意外な落とし穴にはまったり、社内の制約で使用できなかったりするということは案外多くあります。このため、アーキテクチャの検証期間を設けて、この期間内で実際に使用できるかどうか確認を取ることが非常に重要になります。

アーキテクチャの検証とアジャイル的プロセス

前項でトライアンドエラーを繰り返すことがクラウド化を上手く進めるために肝要であることをお伝えしましたが、こちらについて更に詳しく見ていきましょう。

プロジェクト開始時のアーキテクチャは「仮説」に過ぎませんので、検証が必要になります。実際に機能を実装していく中で、様々な制約にぶつかったり、クラウドの仕様に気づいたりするため、その都度アーキテクチャを変更していかなければなりません。
これは、インフラベンダー・クラウドベンダーのみがクラウドのアーキテクチャを構築するのではなく、開発チームとの共同作業で作っていくものだということです。難しいアーキテクチャであればあるほど、開発チームとの共同作業の部分は大きくなっていきます。特に、新しいサービスを使用した新しいシステムを作る場合は、実装の中で分かってくることも多くあるため、実装からのフィードバックを得てクラウドの構築を変えていく必要があるのです。
このため、クラウドベンダーを選ぶ場合は、「作って終わり」というベンダーではなく、開発チームが壁にぶつかった際に一緒に解決してくれるようなベンダーを選ぶのがよいでしょう。

先に「アーキテクチャは仮説である」と述べたように、アーキテクチャの構築は仮説検証を繰り返すため、アジャイル的アプローチとの相性が良いです。反対に、最初にアーキテクチャを決めて、あとは作るだけというふうな進め方は非常に難しくなっています。ウォーターフォール的なアプローチとは相性が悪いため、アジャイル的に途中で柔軟に変更ができるような体制を取ることが望ましいと言えます。

クラウドアーキテクチャのPoCの進め方

こういった検証プロセスを回していくことがクラウドのアーキテクチャを構築するためには必須となっていますが、どのような方法が考えられるでしょうか。

一つの方法として、プロジェクトの前の段階で、アーキテクチャのみのPoCを実施するというものが考えられます。不確実性が高いアーキテクチャに対してPoCを実施することで、先に検証を終わらせておくのは有効です。ここで、実現可能性や性能、コストをあらかじめ測定しておきましょう。作ったアーキテクチャがそもそも動くのかということを検証するほか、コストや性能は事前に計算し切ることが難しいため、PoCの期間を通じてシミュレーションしておくことが望ましいです。また、データの量が多くなると予期せぬ制約が出てくることもあるため、この段階でリスクを潰しておきましょう。

クラウドの導入・活用推進のご相談はNCDCへ

最後に、ここまでご紹介してきた「クラウドの導入・活用推進のポイント」について簡単にまとめておきます。

• クラウドが難しいのは、いままでのシステム構築とは全く異なる考え方でシステム構成（アーキテクチャ）考える必要があるため
• クラウドの良さを最大限活かすには、クラウドの特性を活かした最適な構成（アーキテクチャ）が必要
• 数あるクラウドサービスの中から最適なサービスの中から、最適なサービスを選定できるかがクラウド化成功のポイント
• クラウドサービスの選定にはノウハウが必要
• 会社ごとに制約事項が異なるため、制約事項を変えていく試みも必要
• アジャイル的アプローチでアーキテクチャを考えていくことが重要

NCDCは、クラウドサービス導入前のコンサルティングから、設計、構築、移行、運用まで、トータルでご支援いたします。ノウハウの必要なクラウドサービスの選定はもちろん、漠然とクラウド化を考えているのだけれど……という段階からでもご支援が可能です。
ぜひお気軽にご相談ください。