クラウドストレージアーキテクチャは DevOps のどのような問題を解決できますか?

1. クラウドストレージアーキテクチャの概要

クラウドストレージは、サービスとしてのデータストレージとも呼ばれ、ストレージをオンデマンドで管理できるインターフェイスの背後にあるストレージの抽象化です。さらに、インターフェースはストレージの場所を抽象化するため、ストレージがローカルかリモートか (またはハイブリッドか) は問題になりません。クラウドストレージインフラストラクチャは、多数の潜在的ユーザーに対してさまざまなレベルのサービスと、地理的に分散したストレージ容量をサポートできる新しいアーキテクチャを導入します。データ保護と整合性からストレージの最適化まで、クラウドストレージアーキテクチャの主要なアーキテクチャ属性について学習します。

現在のデータの増加率を考えると、クラウドストレージの人気が高まっているのも不思議ではありません。最も急速に増加しているデータはアーカイブデータであり、コスト、アクセス頻度、保護、可用性など、さまざまな要因によりクラウドストレージに最適です。しかし、すべてのクラウドストレージが同じように作られているわけではありません。あるクラウドストレージプロバイダーは主にコストに重点を置いている一方、別のプロバイダーは可用性やパフォーマンスに重点を置いている場合があります。したがって、どのアーキテクチャも単一の焦点を持っているわけではなく、アーキテクチャが特定の特性を実装する程度によって、その市場と適切な使用モデルが決まります。

実用性という観点から語らずに建築について語るのは難しい。つまり、アーキテクチャは、コスト、パフォーマンス、リモートアクセスなどのさまざまな特性によって評価されるということです。したがって、著者は最初にクラウドストレージモデルを評価できる一連の標準を定義し、次にクラウドストレージアーキテクチャ内の興味深い実装をいくつか検討します。

まず、次の図に示すように、一般的なクラウドストレージアーキテクチャについて説明し、後で独自のアーキテクチャ機能を検討するための背景を設定する必要があります。クラウドストレージアーキテクチャは、主に、高度にスケーラブルでマルチテナント方式でオンデマンドのストレージを提供することを目的としています。一般的なクラウドストレージアーキテクチャには、ストレージにアクセスするための API をエクスポートするフロントエンドが含まれています。従来のストレージシステムでは、この API は SCSI プロトコルです。しかし、クラウド環境では、これらのプロトコルは進化しています。そこには、Web サービスフロントエンド、ファイルベースのフロントエンド、さらにはインターネット SCSI や iSCSI などの従来のフロントエンドも見つかります。フロントエンドの背後には、ストレージロジックと呼ばれるミドルウェアレイヤーがあります。このレイヤーは、従来のデータ配置アルゴリズム（地理的レイアウトを考慮）を通じて、レプリケーションやデータ削減などのさまざまな機能を実装します。最後に、バックエンドはデータの物理的なストレージを実装します。これは、特定の機能を実装する内部プロトコル、または物理ディスクへのレガシーバックエンドである可能性があります。

一般的なクラウドストレージアーキテクチャ図

この図では、現在のクラウドストレージアーキテクチャのいくつかの特徴がわかります。一般的なクラウドストレージ機能のシナリオに固有の機能は 1 つもなく、シナリオに基づいていくつかの重要な機能を選択する必要があることに注意してください。これらの特性は以下の表で定義されています。

機能の中で最も重要なのは管理性とアクセスモードであり、それぞれの意味は次のとおりです。

管理性

クラウドストレージに関する主な懸念事項の 1 つはコストです。顧客がクラウドでストレージをレンタルするのではなく、ローカルでストレージを購入して管理できれば、クラウドストレージ市場は消滅するでしょう。しかし、コストは、物理ストレージエコシステム自体のコストと、それを管理するためのコストという 2 つの大まかなカテゴリに分類できます。管理コストは、全体的なコストの暗黙的ではあるが長期的な要素です。これを実現するには、クラウドストレージがかなりの程度まで自らを管理できる必要があります。自動的に自己構成してクラウドストレージに対応するシステム機能と、エラーが発生したときに検出して自己修復する機能が重要な新しいストレージを導入します。将来的には、自律コンピューティングなどの概念がクラウドストレージアーキテクチャで重要な役割を果たすことになります。

アクセス方法

クラウドストレージと従来のストレージの最も大きな違いの 1 つは、アクセス方法です。ほとんどのプロバイダーは複数のアクセス方法を実装していますが、Web サービス API が一般的です。多くの API は、HTTP (トランスポートとして HTTP を使用) 上に開発されたオブジェクトベースのアプローチである REST の原則に基づいて実装されています。 REST API はステートレスなので、シンプルかつ効率的に提供できます。 Amazon Simple Storage Service (Amazon S3)、Windows Azure、Mezeo Cloud Storage Platform など、多くのクラウドストレージプロバイダーが REST API を実装しています。

Web サービス API の問題の 1 つは、クラウドストレージを活用するためにアプリケーションと統合する必要があることです。そのため、即時の統合を実現するために、クラウドストレージにも共通のアクセス方法が使用されます。たとえば、NFS/Common Internet File System (CIFS) や FTP などのファイルベースのプロトコルや、iSCSI などのブロックベースのプロトコルなどです。 Nirvanix、Zetta、Cleversafe などのクラウドストレージプロバイダーは、これらのアクセス方法を提供しています。

上記のプロトコルは最も一般的に使用されていますが、クラウドストレージに適したプロトコルは他にもあります。最も興味深いものの 1 つは、Web ベースの分散オーサリングおよびバージョン管理 (WebDAV) です。 WebDAV も HTTP に基づいており、Web を読み取り/書き込みリソースとして有効にします。 WebDAV プロバイダーには、Zetta や Cleversafe などがあります。

2. クラウドストレージアーキテクチャは DevOps のどのような問題を解決できますか?

DevOps とは、開発、運用、保守の統合を指します。これは、インターネット企業によって頻繁に採用され、議論される技術です。これは反復的なアプリケーションの基礎でもあります。ある程度、DevOps はクラウドネイティブアプリケーションと同義です。

従来の企業とは異なり、インターネット企業はクラウド環境のニーズに適応するために、クラウドネイティブ設計、マイクロサービス、DevOps、コンテナを採用しています。データストレージでは、データストレージの信頼性の要件を満たすために、複数のコピーと消失訂正符号技術が使用されます。クラウドネイティブはクラウドストレージと完全に統合できますか?業界では通常、クラウドストレージを、クラウドネイティブ機能エコシステムの一部であるコンテナクラウドの基盤となるストレージサポートユニットと見なしています。

まず、クラウドストレージアーキテクチャには多くの利点があり、そのほとんどはコンテナクラウド機能によってカバーされます。その中で、自動化機能、信頼性機能、データ保護機能など、いくつかの利点は DevOps によって再利用されます。 DevOps システムでは、クラウドストレージに「BaaS」という概念用語が付けられています。 BaaS はいくつかのレベルで理解できます。 1 つは、パブリッククラウドがクラウドストレージサービスを提供することです。現状では、パブリッククラウドサービスプロバイダーは通常、製品サービスカタログまたはマーケットプレイスにサービスを統合するためにサードパーティのクラウドストレージベンダーのソリューションに依存していますが、これはパブリッククラウド SaaS サービスとは異なります。一方、クラウドストレージベンダーの中には、自社でサービスを提供しているところもありますが、比較的大きな課題に直面しています。

2 番目のサービスモデルは、データ検証、ハニーポットテスト、セキュリティ検証などの付加価値サービスなど、クラウドに保存されているデータを対象としたサービスを提供するとともに、ユーザーがクラウドからデータを移動してデータコンプライアンス要件を満たすのを支援することです。これもサービスです。

3 番目のタイプのサービスは、多くのユーザーが物理マシンから仮想マシンへ、または仮想マシンからクラウドへ、またはクラウド A からクラウド B へ移行したいと考えているものです。ここではクロスクラウド移行サービスがあり、中間の VCSP パートナーは Veeam のテクノロジーを使用して、このようなサービスの実装を支援します。

3. クラウドストレージ、クラウドコンピューティング、DevOpsの関係

1. クラウドコンピューティングとDevOpsの関係

DevOps の定義は通常、次の 2 つの側面に分けられます。

（１）開発と運用保守のより友好的な関係この定義を使用する企業では、IT 運用は個別に存在しますが、開発者にとって非常に使いやすいものになります。たとえば、DevOps は開発者にインフラストラクチャのプロビジョニング用のセルフサービスカタログと、新しいコードの展開に関するテクニカルサポートチャネルを提供します。

（2）DevOpsは独立した統合されたチームを重視します。この定義を使用する企業では、開発者が運用責任を引き受け、その逆も同様です。

クラウドコンピューティングは新しいネットワークテクノロジーではなく、新しいネットワークアプリケーションの概念です。クラウドコンピューティングの核となる概念は、インターネットを中心に、ウェブサイト上で高速かつ安全なクラウドコンピューティングサービスとデータストレージを提供し、インターネットを使用するすべての人がネットワーク上の膨大なコンピューティングリソースとデータセンターを利用できるようにすることです。この段階では、クラウドサービスとは、分散コンピューティング、ユーティリティコンピューティング、負荷分散、並列コンピューティング、ネットワークストレージ、ホットバックアップ冗長性、仮想化などのコンピューターテクノロジーのハイブリッドな進化と進歩の結果を指します。

DevOps とクラウドコンピューティングの出現は、社会行動の変化とそれに伴うビジネス対応の調整によるものです。 DevOps は、高度で高速かつ中断のないソフトウェアプログラム転送プロセスであり、クラウドプラットフォームは、ソフトウェア実装の俊敏性を推進するパフォーマンスプラットフォームです。クラウドコンピューティングは IT 変革を推進します。ツールと自動化テクノロジーを使用することで、企業はワークフローを短縮し、DevOps プロセスを簡素化して組み込み、効率性を向上させ、真の変化を実現できます。これら 2 つの機能が連携して動作することで、企業は開発を制御し、パフォーマンスを活用し、エラーが発生しやすい環境を排除できるようになります。

2. クラウドストレージとDevOpsの関係

クラウドストレージは、クラウドコンピューティングシステムのカテゴリに属し、インフラストラクチャアズコードのカテゴリにも属します。クラウドストレージと DevOps の統合は、インフラストラクチャアズコードと DevOps の統合のサブ項目です。 Infrastructure as Code は、ネットワーク、仮想マシン、ストレージ、負荷分散などのインフラストラクチャを管理するための記述的な方法です。

インフラストラクチャ・アズ・コードと DevOps の統合は、通常、環境サポート、データサポート、デプロイメントサポートなどのサービス機能を提供することにより、継続的デリバリーフェーズで実行されます。コードとしてのインフラストラクチャは、DevOps のベストプラクティスにおける重要な属性となり、開発者は構成の定義に積極的に関与し、運用チームは開発プロセスの早い段階から関与できるようになります。クラウドストレージを例にとると、運用チームはクラウドストレージ管理ツールを使用してサーバーの状態と構成の可視性を向上させ、最終的には企業内のユーザーに可視性を提供し、チームを結集して効率を最大化することを目指します。自動化は多くの場合、手動プロセスの煩雑さとエラーの発生を軽減し、より効率的かつ効果的にするために設計されています。柔軟性が高く、ダウンタイムが少なく、企業にとって全体的にコスト効率の高い方法で、より優れたソフトウェアとアプリケーションを作成できるようになります。同時に、クラウドストレージが提供するインターフェースサービス、視覚化サービス、監視サービスにより、技術的な複雑さが軽減されながら自動化機能が向上します。この複数チームのコラボレーションアプローチは、DevOps の中心的な考え方でもあります。

4. クラウドデータとクラウドDevOpsの統合方法

初期の DevOps プラクティスでは、クラウドコンピューティングを活用して、データのアクセシビリティを向上させ、コラボレーションを強化しました。ただし、これらの初期の DevOps プラクティスでは、大手のクラウドプロバイダーと契約を結ぶことが多く、より多くのストレージ容量と、より柔軟で簡単にアクセスできる形式が提供されていました。ほとんどの場合、これらの契約はすぐに満足感をもたらしましたが、DevOps 機能が拡張され、DevOps の実践が深まるにつれて、サービス料金とエグレス料金が積み重なり、チームはストレージのニーズを満たすために予算を増やすか、制限に達してデータを失うリスクを負うかの選択を迫られるなど、新たな問題点が明らかになりました。

この状況により、クラウドストレージのジレンマが生じます。企業は、必要以上のクラウドストレージ料金を支払うか、どのデータを保持し、どのデータを削除するかを選択する必要があります。これらの持続不可能なベンダー契約により、ストレージのスケールアップまたはスケールダウンに伴う経済的な問題が生じ、毎日生成および収集される貴重なデータをすべて保存することによるメリットを上回ります。その結果、ほとんどの企業は、すべてのデータを活用してビジネスを推進するのではなく、何をどれだけ保存するかということに頭を悩ませています。

この形式のベンダーロックインは、実験の実施、メンテナンスの実行、新しいアプリケーションの開発と展開に無限とも思える量のデータに依存している DevOps チームに悪影響を及ぼします。

最近の IDC レポートによると、データストレージは今年だけで 59 ゼタバイトに達すると予想されており、今後 3 年間でのデータの作成と消費は過去 30 年間の合計をほぼ上回ることになります。 DevOps は確かにこのピークに貢献していますが、企業が成長し、デジタル変革を続ける中で、直面する最も深刻な問題は、データが王様であり、企業がデータをシームレスに保存、アクセス、活用する能力が、競合他社より目立つようになるということです。

この成長に伴う問題は、特にチームが既存のストレージプロトコルに縛られ、予算を圧迫している場合に、このデータをクラウドに持続的に保存する方法を見つけることです。これは、DevOps チームがアプローチを再考することから始まります。クラウドストレージとアクセス可能性を、請求書とサービス制限の通知の繰り返しサイクルとして考えるのではなく、アーカイブされたデータにアクセスするための追加料金を心配することなく、必要なときに必要なスペースに対してのみ料金を支払う能力に重点を置く必要があります。

ストレージ容量を拡張する必要がある場合、必要なだけの容量を追加できる可能性は低くなります。企業は、特別な理由により規模を縮小したり、ストレージリソースを解放したりする必要がある場合や、短期間でアーカイブされたデータにアクセスする必要がある場合があります。データ容量の弾力的なスケーリングが企業の発展に追いつくことができるかどうかは、実際には DevOps チームが考慮する必要がある問題です。したがって、クラウドストレージでは、ストレージ機能にストレージライフサイクル管理を追加する必要があります。

この変化により、DevOps チームは、データの保存、アーカイブ、破棄から、すべてのデータの収集と活用に移行し、今日のデジタル経済に必要なデータ主導の洞察を推進できるようになります。より大容量のクラウドストレージへの考え方の変化により、制限がなくなり、より迅速かつ持続可能なペースでイノベーションが可能になります。