「クラウドネイティブ」と「クラウド対応」の違い
多くの企業は、従来の環境向けにシステムを開発して、ニーズの変化に応じてシステムをクラウドにプッシュしています。
クラウド対応のシステムは従来の環境で動作し、理論的にはクラウドで機能することが可能です。クラウドにプッシュすることで、しばらくの間は顧客にサービスを提供できます。
しかし、このようなシステムはクラウドを念頭に置いて作られたものではありません。クラウドネイティブのアプローチで構築された場合に比べて、たやすく崩壊する可能性があります。また、クラウドネイティブのアプローチに伴う拡張性、信頼性、安全性のメリットを同様に実現する可能性は低くなります。これが「クラウドネイティブ」と「クラウド対応」の違いです。
クラウドネイティブアーキテクチャのメリットとデメリット
従来のシステムアーキテクチャへの取り組みで問題がなかったのであれば、新しい開発アプローチで必要となる学習に対して警戒心を持つことがあるかもしれません。場合によっては、リスクに値するメリットを得られないこともあります。しかし、クラウドネイティブアーキテクチャには、従来のプロジェクトでは実現できないメリットを一緒に得られることが多くあります。
クラウドネイティブアーキテクチャには、以下のようなメリットがあります。
ただし、クラウドネイティブアーキテクチャには以下のような問題があります。
- デバッグの課題。従来のシステムアーキテクチャで問題を発見することは、直線的な計画に従うことを意味します。クラウドネイティブ設計では、コンテナが相互に作用して接続しますが、その経路は必ずしも明確ではありません。一部の問題は1つまたは複数のコンテナに原因があり、問題を見つけるのは必ずしも容易ではありません。
- セキュリティ。クラウドネイティブで、サードパーティのクラウドオペレーターに依存することは、データとアクセスの制御を譲り渡すことを意味します。それらの企業は、自社ほどデータを慎重に扱わないことがあります。
- 知識のギャップ。クラウドネイティブの手法をとることは、新しい言語を学ぶようなものです。概念を習得し、アプローチを完成させなければならず、小さな間違いが壊滅的な問題につながる可能性があります。
すべての企業は、クラウドネイティブアーキテクチャのメリットとデメリットを慎重に検討し、ビジネス、コンシューマー、ステークホルダーにとって適切な意思決定を下す必要があります。計画に関するディスカッションを早い段階で実施し、ビルドを開始する前にチーム全体がクラウドネイティブアーキテクチャのアプローチを確実に理解することが重要です。
クラウドネイティブインフラストラクチャのアーキテクチャ
クラウドネイティブ環境では、小さなコンポーネントが連携して大規模なシステムを形成します。各部分には特定の役割があり、それらはすべてクラウドで実行されます。各部分のレイアウトは個別に実行できます。最初から最後までシステム全体を作成するわけではありません。
クラウドネイティブ設計はすべて、このように機能します。しかし、自社に最適なシステムを設計するために利用できるオプションはいくつかあります。一般的なオプションは次のとおりです。
- 基本。DNSが2つのロードバランサーのいずれかを選び、アプリケーションとの接続が確立されます。マスターデータベースとスレーブデータベースはキーデータを保持し、アプリケーションと通信します。また、システム全体が定期的にクラウドにバックアップされます。
- マルチクラウド。DNSは、1つのアプリケーションコンポーネントを介して複数のクラウドプラットフォームに接続できます。リリースごとにシステムを複製する必要はありません。アプリケーションコンポーネントは両方の環境で動作し、データはオンプレミスのプラットフォームに戻ります。
- ハイブリッド。DNSが2つのロードバランサーのいずれかを選び、続いてアプリケーションとの通信が行われます。これらのアプリケーションはマスターデータベースにプッシュされますが、そのデータの複製は別のクラウドまたはオンプレミスのスレーブデータベースにプッシュされます。すべてはスナップショットのバックアップにより整理され、保持されます。
図とチャートを使用すると、完了したビルドの外観をチームが理解しやすくなります。また、クラウドアプリケーションを簡単に変更できる点にも留意してください。設計したシステムのサービスに問題があれば、最初からやり直せばいいのです。
ここで重要なのは、クラウド環境にマイクロサービスが不可欠であることです。異なる機能を持つ小さな部分が、ジョブの異なる部分に対処します。これらは独立して動作しますが、システムを稼働させ続けるために相互にリンクされています。これらの小さな部分を含まないものをクラウドに構築してはなりません。
クラウドネイティブアーキテクチャの原則
一部の情報アーキテクトは、最も効果的な学習のためには行動が必要であると考えます。したがって、読んだり聞いたりするよりも、データをコーディングして掘り下げることを好みます。しかし、このアーキテクチャタイプの原則について詳細を把握しても損はありません。それによって、専門家がこれらのシステムを設計する際に何を順守しているかを理解できます。
一般的なクラウドネイティブアーキテクチャの原則は次のとおりです。
- レジリエンスを優先する。冗長性、地域のデプロイ、データの複製は、システムの稼働を維持する上で役立ちます。このようなシステムでは、障害がいずれ発生します。アーキテクトは、それに備えて計画しなければなりません。
- システムはコンポーネントで構成される。アーキテクトは、コンテナを使用して、アプリケーションを相互連携する小さなチャンクに分割します。
- 自動化が重要となる。クラウド向けに設計するときは、オンラインツールを使用してワークロードとコンピューティングの負担を軽減できます。クラウドを構築する上で、自動化が重要な原則となります。
- レイテンシの役割が大きい。どのようなクラウドネイティブシステムでも、ユーザーの要求とシステムのアクションの間にわずかな遅延が生じます。アーキテクトは、これをできるだけ抑制する方法を判断する必要があります。
- バックアップがデータを安全に保つ。システムは並行して構築されるため、クラウドシステムがクラッシュしたり壊れたりしても、失われるものはありません。
- 透明性はシステム設計の一部である。コンテナは、ブラックボックスのように構築できます。しかし、各コンテナにある程度の浸透性を持たせることで、観察し、うまく機能していることを確認できます。この透明性により、自動更新も可能になります。
多くのコーディングチームが、クラウドネイティブアーキテクチャをどのように扱うかについてのブログやマニュアルを書いています。それらに目を通すことで、同じ課題に対して他者がどのように取り組んでいるのか知ることができます。
非対象暗号化に対するOktaの支援
世界トップクラスの技術組織の多くは、クラウドネイティブアーキテクチャを使用して、ソフトウェアを迅速かつ安全に提供しています。顧客からのフィードバックに対して、迅速に行動して対応できる能力は、中小企業にとっても大企業にとっても非常に貴重です。
しかし、このタイプのアーキテクチャのメリットを実現していないクラウドベンダーも存在します。Oktaはお客様のニーズを重視し、ベストプラクティスに従うと同時に優れた機能を発揮するシステムを構築しています。皆様からのお問い合わせをお待ちしております。
参考文献
Cloud Native Computing Foundation Charter. (December 2018). The Linux Foundation.
Introduction to Cloud-Native Applications. (May 2020). Microsoft.
3 Reasons to Go Cloud-Native. (August 2018). The Wall Street Journal.
Cloud-Based vs. Cloud-Native Application Development: An Important Distinction. (September 2018). Digitalist Magazine.
5 Principles for Cloud-Native Architecture: What It Is and How to Master It. (June 2019). Google.
Cloud-Native Application Architecture. (February 2019). Medium.
How to Architect and Design Cloud-Native Applications. (December 2015). Gartner.
Cloud-Native Principles. IBM.
