DATA MANAGEMENT
新たなWasabi API Reference CenterでAPIファーストを実現
これまで、欠けているパラメータ探しや古くなったAPIドキュメントの読解に苦労したことがあれば、質の悪いドキュメントがどれだけの時間を浪費することになるかをご存じのはずです。こういった状態は集中力の妨げとなるだけでなく、エラーの確認に追われ、機能を構築することができずにリリースが遅れる原因となります。
そのため、WasabiではAPIファーストのアプローチを採用し、開発者向けのドキュメントとツールを根本から再構築しました。本稿では、新機能とその重要性、そして新しいWasabi API Reference Centerが開発のあらゆる側面を効率化する方法について解説します。
より速く、よりスマートに、よりインタラクティブな体験をもたらすWasabi API
Wasabiは、クラウドストレージを高速・予測可能・シンプルにすることを目指してきました。その使命を果たすうえで重要なのが、信頼性の高い統合を実現することです。そこで導入したのが、開発者がAPIを探索、テスト、展開する際に役立つインタラクティブな統合環境であるWasabi API Reference Center’(英語ページ)です。
Wasabi API Reference Centerでは、S3互換ストレージ、WACM Connect、アカウント制御、統計などを含むすべてのAPIガイドを直感的で操作しやすいポータルにまとめています。
主なポイント:
主要なAPIガイドに実行環境が組み込まれており、ブラウザ上で直接リクエストを試せる
明確かつ最新なエンドポイント定義、リクエストおよびレスポンス構造、エラーコード、認証方式、サンプルペイロード
命名規則、バージョン管理、進化の指針を含め、最新のAPIファースト原則に沿って一貫した構成
すばやく参照できるPDFエクスポートと、より理解を深められる相互リンク
また、Wasabi AiRおよび関連API用のPostman Collectionも公開しました。これには、事前に設定されたリクエスト、APIキーの環境変数、そして認証からデータクエリまでを網羅するサンプルフローが含まれています。これにより、以下が可能になります。
URLテンプレート、ヘッダー、ペイロード本文が事前構成されたリクエストをインポート
環境変数(ベースURL、APIキーなど)を使用し、テストを簡素化
すべてのリクエストをゼロから手動でコーディングすることなく、認証→リソース作成→クエリをエンドツーエンドで実行
このようなアップデートによってテストをスムーズに行えるようになり、オンボーディングが高速化します。
APIファーストが重要な理由
こういったアップデートの背景には、「APIファースト」と呼ばれる指針があります。これは、APIを使用するアプリケーションやツールを構築する前に、まずAPIそのものを設計および定義するという考え方です。つまり、エンドポイント、パラメータ、レスポンス、認証方式などの仕様を先に固めてからアプリケーションロジックを記述することを指します。こうすることで、APIはすべてが組み込まれた単一かつ信頼性の高い基盤となります。
APIファーストによってもたらされるメリットには、以下のようなものがあります。
柔軟性の向上:同じAPIを介してすべてのアプリケーションが接続されることで、既存の動作を中断することなく、個々の機能の追加・変更が可能になる
より高い一貫性:すべてのエンドポイント、パラメータ、動作が一度定義され、あらゆる場所で再利用されるため、システムが予測可能かつ管理しやすくなる
オンボーディングとイノベーションの実現を高速化:詳細な例とライブテストにより、仕組みを簡単に理解し、すぐに構築を始められる
容易なメンテナンス:組み込みのバージョン管理と下位互換性により、下流への影響を最小限に抑えつつ更新することが可能
エコシステムの成長:クリーンで一貫性のあるAPI構造で、新しいツールや統合を通してパートナーや開発者コミュニティがプラットフォームを拡張しやすい
APIファーストは単なる設計哲学ではなく、信頼性と拡張性の高い開発を可能にするものです。
開発者とパートナーのエクスペリエンスを向上
多くの人々は、まずは何かを壊すことからAPIを学びます。API Resource CenterとPostman Collectionを使用すると、その作業がより高速かつ安全になります。つまり、呼び出しのテスト、応答の確認、調整や再実行が、クライアントを立ち上げたり見落としたヘッダーを推測したりすることなく行えるようになります。また、すべてが可視化され、テストや共有の作業もよりスムーズになります。
チームでは、Postman環境をフォークしたり、バージョン管理に更新をプッシュしたり、ステージング用に独自のベースURLを入れ替えたりすることができます。その結果、「自分の環境だけでしか動作しない」という問題が減り、環境をまたいだ再現性が保証されます。
このアップデートは、統合を行う開発者だけでなく、Wasabi APIを使用してストレージワークフローや分析ツールを接続するパートナーにとってもメリットがあります。新しいドキュメントとツールを使用することで、プロトタイプの迅速な作成や独自の問題解決が可能になり、リリースを遅らせるやり取りなしで容易にプロジェクトを進めることができます。
つまり、企業パートナーと開発者の両方にとって、よりスムーズな提供、予期せぬトラブルの減少、そしてより確実な連携につながります。
Wasabiによるテストと改善で新たなアプローチを推進
APIファーストを目指すのであれば、APIを機能させる要素である仕様、ツール、フィードバックループに早い段階で投資する必要があります。これによって、ドキュメントが劣化し、チームが拡大し、新しい統合がオンラインになったときにも、APIの信頼性を維持することができます。
Wasabi API Reference Centerの目的は単にドキュメントの改善だけではなく、APIを構築する人々とAPIを利用する人々のフィードバックサイクルを改善することです。そのため、ドキュメント、プレイグラウンド、サンプルはすべて、開発者の実際の作業方法を反映するように構築されています。
開発者やパートナーの皆さまは、ぜひWasabi API Reference Center(英語ページ)をお試しいただき、Postman Collectionをインポートしで迅速な統合をご体験ください。
フィードバックや機能についてのリクエストがある場合はLinkedInにてぜひご共有ください。
最新のAI対応のデータレイクは、耐久性があり、予期せぬコストが発生しないデータ基盤を構築するという、分かりやすい問題を解決するためのものでした。しかし、生成AIの登場により、データアーキテクチャはもはや単なるバックグラウンドのインフラではないことが明らかになりました。多くの場合、それが最大のボトルネックとなっています。生成AIは通常、モデル、GPU、フレームワークといった観点から語られます。しかし実際には、最初のボトルネックはもっと早い段階、つまり「データ」で発生します。トレーニング、ファインチューニング、検索、推論、継続的学習といったライフサイクルのあらゆる段階は、大量の非構造化データへの持続的かつ反復的なアクセスに依存しています。初期のアナリティクスのワークロードとは異なり、生成AIは「一度書き込んで、たまに読み取る」というパターンには従いません。データは次のように扱われます:実験やイテレーション(反復)を通じて継続的に再読み込みされる埋め込み(エンベディング)、インデックス、プロンプト、出力などの派生アーティファクト(生成物)に変換される再現性、ガバナンス、再トレーニングのために長期保存される変化の激しいコンピュート(計算)層から切り離される問題は、多くのクラウドストレージプラットフォームがこのような「再利用」を想定して設計されていないことです。Wasabiのオブジェクトストレージは、従来のクラウドの常識に逆らい、ストレージの経済性とアーキテクチャを、生成AIのワークロードの実際の動作に合わせています。新興の生成AIワークロード:ストレージへの要件生成AIのワークロードはすべて同じというわけではありませんが、「非構造化データへの反復アクセス」という共通点があります。主要なパターンと、それがストレージに何を要求するかを以下に示します。基盤モデルのトレーニング 基盤モデルのトレーニングは、テキスト、画像、音声、動画などの膨大な非構造化データセットに依存しており、トレーニングの実行や実験のたびに繰り返し読み込まれます。 ストレージの観点から見ると、これらのワークロードは以下の特徴を持ちます:読み取り集約型でスループット重視レイテンシよりもコストの予測可能性に敏感アーカイブの効率性よりも「データの再利用」に依存問題は、従来のクラウドストレージモデルでは、読み取りやデータの移動に対して課金(マネタイズ)されることが多い点です。この価格設定は、AIトレーニングに必要な反復アクセスパターンには逆効果です。 Wasabiは、アクセスベースの課金ではなく、容量ベースの価格設定を中心に構築されています。読み取りや下りデータ転送に対するペナルティ料金を排除することで、コスト変動の恐怖やアーキテクチャ上の妥協をすることなく、データを自由に再利用して実験を繰り返すことができます。ファインチューニング、アライメント、反復的なモデル開発 種類のプレッシャーをもたらします。データセットは小さくなりますが、変更頻度は高くなり、結果が再現可能で追跡可能であるようにデータを慎重に保存する必要があります。これらのワークフローには以下が必要です:データセットの不変性(イミュータビリティ)とバージョニングデータと、それが生成するモデル間の明確なリネージチーム間での並行実験階層化や手動のライフサイクル移行に大きく依存するストレージでは、ここで足かせになり始めます。Wasabiは、データを異なるストレージクラスに移動させることなく、大規模なオブジェクトの不変性とバージョニングをサポートします。データセットは安定してアクセス可能な状態を保ち、チームはガバナンスを維持したまま迅速に開発を反復できます。検索拡張生成(RAG)RAGは、生成AIがもたらした最大のアーキテクチャ的変化の1つです。 RAGパイプラインは継続的に非構造化コンテンツを取り込み、強化し、埋め込みを生成し、推論中に関連するコンテキストを検索します。ベクトルデータベースは類似性検索には優れていますが、記録システムではありません。 アクセスにペナルティを与えたり、データ移動に高額な料金を課したりするストレージモデルは、分離されたRAGアーキテクチャを必要以上に脆弱にし、コストを押し上げます。Wasabiを使用すれば、未加工データや強化されたデータを耐久性のある「信頼できる情報源」としてオブジェクトストレージに保存し、反復アクセスにかかるコストを予測可能に保つことができます。推論、フィードバックループ、継続的学習 推論はデータの増加を遅らせるどころか、加速させます。プロンプト、出力、ユーザーのやり取りは、監査、モデル評価、将来の再トレーニングのために保持される傾向にあります。時間とともに、推論データは次世代モデルの重要な入力となります。 Wasabiの容量優先の設計は、データ移行を強制したりアクセスにペナルティを与えたりすることなく、大量のデータ取り込みと長期保存をサポートします。AI対応データレイクからAI駆動型ビジネスインテリジェンスへAI対応データレイクの構築は出発点にすぎません。真の価値は、そのデータが「使いやすくなる(照会しやすく、強化しやすく、日々の意思決定を加速する答えに変換しやすくなる)」ことで現れます。 社内的には、Wasabiのビジネスインテリジェンス(BI)チームは、WasabiオブジェクトストレージとSnowflakeを組み合わせてこのパターンを適用し、セールスチーム向けに生成AIレスポンスを提供しています。未加工の資産(PDF、プレゼン資料、ログなど)はオブジェクトストレージに保存され、長期間にわたって経済的にアクセス可能な状態を維持します。一方、Snowflakeは構造化されたインテリジェンス層として機能します。なぜ生成AIは従来のストレージの常識を打ち破るのかほとんどのクラウド・オブジェクトストレージは、生成AIの世界では通用しない次のような前提に基づいて構築されていました:データは一度書き込まれ、めったに読み込まれないストレージ階層化がコスト最適化の主な方法であるストレージの経済性は、コンピュートの革新ほど重要ではないデータは単一のエコシステムに密接に結びついている生成AIは、これらの前提の限界を露呈させます。再読み込みが高額になると、運用チームはクリーンなシステムを構築するのではなく、コストを回避するためのアーキテクチャ設計を始めてしまいます。Wasabiは、以下の点を優先することでこれらの制約に逆らいます:アクセスベースの価格設定よりも、予測可能な経済性階層化の複雑さよりも、データの再利用性特定のエコシステムへのロックインを防ぐ、柔軟でポータブルなアーキテクチャバックエンドサービスではなく、戦略的インフラとしてのオブジェクトストレージ生成AI対応のオブジェクトストレージ・アーキテクチャトレーニングからRAG、推論に至るまで、共通のアーキテクチャパターンが現れます:オブジェクトストレージが耐久性のある「記録システム」として機能するコンピュート層はモジュール式で交換可能にするメタデータ、不変性、アクセス制御はストレージ層で適用される派生した生成物は使い捨てで再生成可能にするアーキテクトとプラットフォームチームにとっての意味生成AIプラットフォームを構築する場合、以下の点が不可欠となります:ストレージを後回しにせず、最優先の依存関係として扱うデータの再利用を容易かつ手頃な価格にする未加工データは「永続的」、派生アーティファクトは「使い捨て」として扱う経済性がシステム開発の反復(イテレーション)を妨げるのではなく、可能にするようにするオブジェクトストレージは、もはや単なるデータの保存場所ではありません。システムが迅速に動き、ガバナンスを維持し、コストのサプライズなしに拡張できるかどうかを決定づける重要な要素なのです。新興のAIワークロードは、常識に逆らうストレージを求めている生成AIシステムは、反復、再利用、そして洗練を重ねることで向上していきます。アクセスにペナルティを与えたり、厳格な階層化を強制したり、データをコンピュート層に密接に結びつけたりするストレージアーキテクチャは、あらゆる段階でそうした現実と相反してしまいます。従来のクラウドストレージモデルの常識に逆らうことで、Wasabiはオブジェクトストレージを、AI対応データレイクから本番環境の生成AIシステムに至るまで、新興の生成AIワークロードの実際の動作と適合させています。これにより、チームは技術的、運用的、そして経済的に長期にわたってスケールできるプラットフォームを構築できるようになります。...
多くのCISOは、データストレージをあまり重視していません。アイデンティティ管理、アクセス制御、検知、ガバナンスを同時に管理する立場では、何かしらの問題が起きない限り、背後で働くインフラにまで目が届かないのです。そのため、サイバー脅威が発生したり、最悪のタイミングでバックアップが失敗したりして初めて、ストレージに意識が向けられることになります。実のところ、レジリエンスは単にバックアップ頻度だけの問題ではありません。重要なのは、データがどれだけ適切に保護されているか、そして問題が発生した場合にどれだけ迅速に復旧できるかという点です。そのためストレージの保存先は、ファイアウォール、エンドポイント、アクセス制御と同じく非常に重要です。ストレージが不変性、アクセス性、そして手頃なコストでテストを行える状態を考慮して構築されていない場合、想像以上のリスクを負うことになります。今こそ一歩下がって、全体的なレジリエンス計画におけるストレージの役割を見直すチャンスです。以下の質問をチームに投げかけることで、重要なタイミングで組織が効果的に回復できる状態かどうかを確認することができます。1.自社のストレージは本当にビジネスリスクを下げているか?バックアップは、ただ作成するだけで評価される傾向にあります。チェックリストを満たして監査に対応することで、安心感が生み出されるためです。しかし、その安心感がレジリエンスになるわけではありません。本質的なポイントは、バックアップがどこに保存されてどのように保護され、問題が発生した際にどれだけ確実に復旧できるかということです。つまり、ストレージをリカバリ戦略の基盤として考えてみてください。あらゆるバックアップの保存先となるストレージの復元力が不十分だった場合、データ保護計画も脆弱になります。真にサイバーレジリエントなストレージは、攻撃者、内部関係者、さらには運用コストに足を引っ張られず、クリーンな復元を可能にする安全性と耐久性を兼ね備えています。まず、バックアップデータが主要な運用システムから分離されたセカンダリストレージに保存されているかどうかを確認しましょう。次に、アーキテクチャ自体を詳しく調べます。イミュータブル機能によって、データの保存期間が終了するまで変更や削除ができない状態になっていますか?AES-256などの最新標準を使用して、転送中および保存中のデータが暗号化されるようになっていますか?多要素認証(MFA)によって、アカウントへのアクセスが安全に管理されていますか?単一の認証情報でバケットやアカウントを独自に削除されないように、マルチユーザー認証(MUA)などの機能を導入していますか?こういった制御があるかどうかで、レジリエンスが迅速で検証可能なものになるか、高額な割に不確実なものになるかが分かれます。また、依然としてゴールドスタンダードとして挙げられるのが3-2-1-1-0ルールです。これは、3つのデータコピーを2種類の媒体に保存し、そのうち1つはオフサイトに、もう1つは不変の状態に保つ手法で、復旧後のエラーをゼロにすることを目的としています。ストレージがこれらの条件を満たしていない場合、ダウンタイムのリスクがあるだけではありません。この状態では単にレジリエンス戦略を夢見ているだけで、実際には何も整っていないことを意味します。2.理論的にではなく、実際にテスト可能なレジリエンスを構築しているか? すべてのストレージがレジリエンスを前提としているわけではなく、リスクの恐れがあります。データのバックアップは多くの環境で問題なくできても、「データを復元する」のは非常に困難です。いくつかの重要な機能があるかどうかで、いつでも復旧できる状態になるか、それとも時間との戦いになるかの違いが生まれます。まず土台となるのが、クラウドオブジェクトストレージです。これは耐久性、拡張性、リージョン間の冗長性を考慮して設計されており、単一の障害で全体が停止することを防ぎます。問題が発生した際に業務を安定させるバックボーンとなる存在です。続いて、基本的な要素が揃っているかどうかを確認します。イミュータブル機能:データを書き込み後、保持期間が終了するまで不変性が維持される機能です。これにより、ランサムウェアや誤削除からクリーンなコピーを保護することができます。あらゆる場所での暗号化:AES-256などの強力な最新標準によって、転送中および保存中のデータを暗号化しましょう。また、最も簡単にデータ流出を防ぐため、キーを定期的にローテーションすることも重要です。ゼロトラストアクセス:ストレージは、自社の他環境と同じ原則に従う必要があります。つまり、暗黙の信頼は置かず、誰一人としてすべてを削除できる権限を持たせないことが重要です。マルチユーザー認証では、データ損失につながりうるアクションに対して複数の承認を要求することで、これを実現します。手頃なコストの復旧テスト:高額なAPI料金や下り転送料が課せられる場合、十分な頻度でテストが行われなくなります。定期的かつ妥協せずにテストを繰り返してこそ、データの復元が可能になります。また、テストを行うことで、復旧スピード以外に2つの基本事項を確認することができます。想定するデータが本当にバックアップされているかどうか、および、そのデータは実際のインシデント発生時に回復する必要がある内容かどうかということです。以上のポイントはそれぞれ、復旧チェーンの異なる部分を守ります。すべてが組み合わさることで、データの完全性、アクセス性、復元可能性という、レジリエントな組織に不可欠な3つの要素が保証されます。3.予算内かつSLAを守りながら復旧できるか?どんなに優れた防御策であっても、決して失敗しないということはあり得ません。ポイントは、問題が発生した際の復旧速度です。これによって、ビジネスへの影響が軽度なものでおさまるか、大規模な停止に陥るかが決まります。復旧計画がきちんと文書化されている場合でも、それが実行可能かつ、十分な頻度でテストされていなければ意味がありません。まず、ストレージとバックアップシステムがフェイルオーバーをどのように処理するかを確認します。重要なアプリケーションを迅速に復元できる状態か、もしくはデータがどのクラウド層に存在するかによって復元時間が異なるかどうかを確かめましょう。また、コストについても正直に向き合う必要があります。コールドストレージは一見、お手頃で良い選択肢に思えますが、大規模な復旧時に役に立たない場合があります。高額な下り転送料が掛かったり、インシデント発生時にデータ取得するために何時間も待たされたりすると、節約したコストもすぐに消えてしまいます。続いて、アクセスやリカバリにかかる時間について、ストレージプロバイダーのサービスレベル契約が社内のRTO(目標復旧時間)と一致しているかどうかを確認しましょう。RTOは、インシデント発生後にシステムとデータをどれだけ早くオンラインに復旧できるかを示すものです。そのスピードによって、業務停止の長さ、失われる信頼や収益、そして問題に対処できたと証明するまでの時間が左右されます。次に、RPO(目標復旧ポイント)です。ここではより具体的に、最後のバックアップからどのくらい遡ってデータを復元できるかを確かめます。これは、バックアップがどのくらいの頻度で行われるかによって完全に異なります。ストレージコストが経済的かつ予測可能であれば、頻繁にバックアップをすることでデータ損失の可能性を減らすことができます。コストが原因でバックアップの間隔を長くせざるを得なくなった場合、その分リスクが増大します。最後に、テストの頻度とコストを確認します。復旧テストは少なくとも四半期ごと、ビジネスのなかで重要もしくは更新頻度が高いシステムの場合は、より頻繁に行う必要があります。下り転送料またはAPI料金が課されるストレージプロバイダーを選んでいた場合、復旧テストの頻度は次第に減っていきます。テストが行われなくなることは、その分の信頼も低下することを意味します。費用もしくは時間がかかりすぎるテスト計画は、単なる机上の空論に終わります。定期的かつ手頃な価格でテストを実施することで、サイバーレジリエンス戦略のあらゆる側面が裏付けられます。4.自社のストレージがコンプライアンスと監査の要件を満たしているか?コンプライアンスは単なる形式的なものではなく、制御が機能していることを証明する責任を担います。ストレージはこの点において、多くの人が認識しているよりも大きな役割を果たしています。まず、組織に適用される規制と内部ポリシーを確認します。HIPAA、FERPA、GDPR、SOXなどのフレームワーク、またはPCI DSS、CJIS、FedRAMPなどの業界標準は、データ保持、プライバシー、セキュリティの領域で重なり合う部分が多くあります。これは、データの保存場所、暗号化、アクセス方法など、あらゆるストレージの決定がコンプライアンスに関わることを意味します。また、新たなEU規制により、監視がさらに強化されました。サイバーレジリエンス法とEUデータ法は、サイバーセキュリティ、データガバナンス、透明性に関する新たな義務を課しています。これらは、データの保存および保護方法を示すだけでなく、レジリエンスと信頼性の基準がより広範かつ世界的に引き上げられたことを反映しています。そのため、ストレージはコンプライアンスを実際に満たす機能を備えている必要があります。以下の要件を満たすかどうか、ストレージチームと確認してください。保持と不変性:規制の対象となるデータは、保存期間全体にわたって保持され、変更または削除できない状態になっていますか?イミュータブル機能とバージョン管理を導入することで、監査が求める保証が提供されます。暗号化とキー管理:機密データは、AES-256などの強力な最新標準を使用して、転送中・保存時に暗号化されていますか?キーは定期的にローテーションされ、ストレージ資格情報とは異なるキー専用管理サービス(KMS)で管理されていますか?ゼロトラストの原則:ストレージ環境では、管理アクションに対して最小限の権限、継続的な検証、職務の分離が課されていますか?MUAなどの機能を通して、内部リスクを減らすことができます。監査への準備と可視性:監査の際、データアクセス、保持、復旧に関するエビデンスをどれだけ迅速に提示できますか?ログとメタデータは、規制当局の基準を満たしていますか?これらのポイントの中で何かしらの不明点がある場合は、そこをさらに深掘りする必要があります。暗号化、不変性、専用キー管理、透明性のある監査ログをサポートするストレージは規制要件を満たすだけでなく、セキュリティとコンプライアンス全体にわたる信頼性を強化します。まとめレジリエンスは偶然手に入るものではありません。不可避のトラブルを想定した計画・テスト・適応を通し、意図的に積み重ねてゆくものです。ストレージはレジリエンス全体において目立つ要素ではありませんが、残りの部分がどれだけ早く復旧できるかを決定づける存在です。本稿で取り上げた不変性、アクセス、テスト、コンプライアンスに関しての質問は、今後の対応が可能かどうかを確認する指針となります。こういった問いかけに答えられない部分があったとすれば、そこが着手し始めるべきポイントということです。レジリエンスはただ考えるだけでなく、検証があってこそ構築されます。復元をテストすることで、最悪の事態が発生した場合でも組織が事業を継続できるという自信につながります。...
マネージドサービスプロバイダー(MSP)にとって、クラウドバックアップの設計は、サイバー攻撃から顧客を守るだけでなく、自社のイノベーション、差別化、利益率の向上にも影響します。市場における脅威が激化し、収益が圧迫されるなかで、選んだベンダーに隠れたコストや制約があった場合、業界をリードできるか否かが大きく左右されます。イノベーションや競争力について考えるとき、データの保存方法は最優先事項ではないかもしれません。しかし実際には、それこそが将来を見据えた戦略の基本的な要素なのです。データの保存とバックアップは、ランサムウェア攻撃、システム障害、データ破損、ITエラーによるビジネスへの影響を最小限に抑える上で重要な役割を果たします。必要なときにいつでも適切なデータをすぐに利用できるかどうかは、予算の柔軟性や、新しい機能やサービスを提供して他社と差別化を図れるかどうかにも大きく影響します。Data Protection Mattersが発行した2025年のホワイトペーパーでは、今後数年にわたってサイバーレジリエンス、コスト管理、イノベーションを継続的に両立させるには、オープンかつハイブリッドなクラウドバックアップ戦略が必要とされています。ハイブリッド戦略とは、データバックアップの冗長性と保護、およびクラウドプロバイダー間の相互運用性を実現する分散クラウド基盤の構築を意味します。これにより、複数のプロバイダーのサービスと機能を柔軟に組み合わせ、ビジネスの将来性をさらに高めることができます。技術面・コスト面での懸念事項成功するデータストレージやクラウドバックアップ戦略に組み込むテクノロジーの選択は、経済的な判断と密接に結びつきます。技術面では、「プロバイダー中立」のオープンエコシステムを採用することで、さまざまな場所にバックアップを保存する際のデータ損失やアクセス不能のリスクが軽減されます。これにより、どこか一箇所で障害が起きても影響を最小限に抑えられ、特定のプロバイダーや単一障害点に依存しない構成が可能になります。オープンクラウドのエコシステムでは、個々の顧客のニーズを満たす最善のサービスを厳選できます。そのため、Amazon Web Services(AWS)、Microsoft Azure、Google Cloudなど、従来のハイパースケールプロバイダーによるベンダーロックインを回避することが可能です。また、これらのクラウドネイティブプラットフォームでは、下り転送料が長年にわたるマイナスポイントとなっています。さらに、新たな懸念として挙げられるのが、ソフトウェア、ストレージ、セカンダリボールトを単一のクローズド環境にまとめた「シングルスタック」バックアッププラットフォームの台頭です。このモデルは一見便利に見えますが、データを独自のエコシステム内に閉じ込めるため、別のストレージプロバイダーやクラウド、インフラへ移行しようとすると、高額な再設計が必要になります。かつてのITサイクルでも起こったように、このような制約はいずれ、イノベーションを阻害する要因となります。単一のプロバイダーによる結合サービスのみに依存すると、顧客に提供できるオプションや機能が制限されることになります。コスト面では、ハイパースケールプロバイダーの場合、隠れた手数料でMSPの利益を圧迫する傾向にあります。イミュータビリティ(不変性)、レプリケーション、オブジェクトのサイズ設定といった機能には追加料金がかかり、すぐに費用がかさみます。こういったコストが原因で、完全なデータ保護や定期的な復旧テストを行いにくくなり、結果としてセキュリティとコンプライアンスにギャップが生じることになります。しかし、こうしたサービスや価格モデルに縛られ続ける必要はありません。ハイパースケールストレージからの転換 おそらく、あなたの組織や顧客は、AWS、Microsoft、Googleなどの主要なクラウドストレージサービスに大量のデータを保存していると思われます。なぜなら、拡張性の高いクラウドストレージを最初に市場に投入したのがこれらのサービスであるためです。これらのプロバイダーは、急増するデータ量を処理するために、独自のルール、料金、制限を持つ複雑なストレージ階層(ホット、クール、コールド)を構築しました。その結果、隠れたコスト、運用の複雑さ、ベンダーロックインという懸念点が生まれ、今ではMSPの足かせとなっています。たとえば、データ複製、イミュータブルバックアップ、復旧時間と復旧ポイントのテストなどを行えば行うほど、ハイパースケーラーでは追加料金が増えていきます。これらの企業は、データの上り・下り転送、APIコール、ストレージに対して「従量課金」制で料金を請求します。これでは予測が難しく、予算化がほぼ不可能です。サイバーセキュリティの観点では、災害復旧計画のテストに高額な下り転送料がかかることで、本来であれば事業継続のために行うべき定期的な復旧テストの実施をコスト面で諦めなければならない状態に陥ります。クラウドのコストと管理の削減を検討していても、自社と顧客のデータを適切に保護しようとするとますますコストがかかり、管理が複雑になるのです。一方、オープンエコシステムを採用すると、業界標準の相互運用パートナーシップによって、ハイパースケーラーのサービスからWasabi Hot Cloud Storage(詳細は後述)などの他のクラウドにデータストレージを拡張できるようになります。その結果、シンプルかつ最適な価格モデルを選択が可能になります。また、復旧時にはデータへ即時にアクセスでき、重要なバックアップを複数のクラウド基盤に分散させることで、冗長性と保護が高まります。先述のとおり、ハイブリッドクラウドストレージとバックアップは、特定のクラウドで発生したインシデントによるデータ損失やアクセス不能のリスクを低減します。ストレージが重要な理由とWasabiの役割 将来を見据えたクラウドバックアップ戦略を実現するには、ハイブリッドクラウドストレージとバックアップサービスを統合する必要があります。クラウド、オンプレミス、あるいはMSP拠点に導入された主要バックアッププラットフォームとストレージを統合することで、データを包括的に保護し、サイバー攻撃、システム停止、偶発的なデータ損失といったインシデントから迅速に復旧することが可能になります。Wasabiは、高速アクセスと回復性を備えた業界をリードするパフォーマンスをお手頃な価格で提供し、Veeam、Commvault、Cohesity、Rubrik、HYCUなどの主要パートナーの多様なバックアップサービスと連携しています。すべてのデータはプライマリデータとしてアクセス可能であり、クローズドなシステムでありがちな、「コールド」ストレージ(安価だが総所有コストは低くならない)からの取得遅延を回避できます。WasabiのホットストレージはAWS...
