DATA PROTECTION
Backup as a service (BaaS) を利用すべき7つの理由
データのバックアップをこれまでと同じやり方で行うのは、もはや現実的な対策とは言えません。バックアップは電子メールと並んでコンピューターシステムに不可欠な機能です。また、企業のデータは意思決定と新たな成長を促す生命線となるため、災害が発生した場合に備えてデータの安全性を高めることが重要です。データを保管する場合、かつてはストレージサーバーのバックアップラックや専門家を頼る必要がありました。しかし、「As-a-Service」革命が起きたことで、特にクラウドベースのバックアップを重視するマネージドクラウドコンピューティング企業に大きな変化がありました。バックアップは今や、オンプレミスストレージの年間メンテナンスよりもコストを抑えながら、オフサイトで実行することができます。本稿では、信頼性の高いBackup-as-a-Serviceプロバイダーでクラウドをバックアップすべき7つの理由をご説明します。
あらゆるAs-a-Service
「As-a-Service」を使用する主なメリットは、使用量に応じた料金システムで多額の初期費用を削減し、サービスを導入しやすくなることです。企業でデータをバックアップする場合、ハードウェアではストレージ容量に悩まされることがありますが、Backup-as-a-Serviceの場合、アップグレードすることなく、チームの成長に合わせてストレージを簡単に拡張できます。データの増加は2年ごとに倍増すると予想されています。そのため、データ中心のビジネスを構築する上でこのような柔軟性は不可欠です。
企業データバックアップの付加価値にフォーカス
IT組織にとって、バックアップは不可欠ではあるものの専念すべき業務ではありません。クラウドにおけるBackup-as-a-Serviceは通常、一度設定すればその後は手間がかからないプロセスが自動で適応されます。しかし、従来のオンプレミスバックアップでクラウドと同じレベルの冗長性を実現しようとすると、継続的な維持と調整が必要になります。オンプレミスのバックアップに頭を悩ませる時間があれば、マーケティングや販売システム、モバイルワーカー、AI、機械学習、デジタルトランスフォーメーションなど、ビジネスの価値を実質的に向上させるプロジェクトを展開できます。
CAPEXからOPEXへのシフト
「As-a-Service」が広まったことで、資本支出(CAPEX)モデルから運用支出(OPEX)モデルへ移行しました。Software-as-a-Service(SaaS)が従来のソフトウェア購入の初期コストを削減したのと同様に、OPEXはIT予算の初期コストを削減します。多くの企業が好む購入モデルを使用することで、問題の発生時にチームで対処できるようになります。
無限のストレージ容量
企業でデータのバックアップをどうするか決める際、容量を元に考えるのは避けるべきです。つまり、データを保持するか削除するかの決断は、サーバーのバックアップ能力に左右されるべきではありません。しかし、従来のオンプレミスソリューションではコストがかかるうえ、容量が不足した際のアップグレードも困難でした。一方、クラウドベースのBaaSオプションはエクサバイトレベルまで拡張できるように設計されており、保存できるデータ量に実質上の制限がありません。
低コストで高品質な専門知識を提供するサーバーバックアップ
BaaSの料金は、クラウドに保存するデータ量(場合によっては、クラウドから取り出すデータ量)に基づいて課金されます。しかし、BaaSには無料のメンテナンス機能も組み込まれています。そのため、通常であればサーバー管理に高額なコストと人材を投入する必要がありますが、BaaSでは追加コストなしで処理することができます。
簡単に企業データをバックアップできるベストプラクティス
Wasabiでは、バックアップの3-2-1のルールを採用しており、3つのコピーデータのうち2つをメディアで、1つをオフサイトで保管します。従来のオンプレミスバックアップではこの標準を達成するのは困難でしたが、クラウドはストレージのベストプラクティスをすべて満たしています。さらに、プロセス全体を自動化できるため、データの冗長化がさらにシンプルになります。不変性を備えたS3オブジェクトロックなどの機能を追加すれば、ランサムウェアにも対応する無敵のセキュリティソリューションが手に入ります。
災害復旧への小さな一歩
データのバックアップをオフサイトに保存しておくことは、災害が発生した場合に主要なインフラを保護するうえで非常に有効な手段です。従来、データをオフサイトに移動するには、業者の手配や繊細な物理メディアの取り扱い、そして多くの時間とコストが必要でした。しかし、クラウドを利用すれば、バックアップとリカバリを数秒で自動的に実行できます。オフサイトのデータセンターから復元することで、サービスの中断を最小限に抑えながら迅速にデータを回復することができます。
As-A-Serviceスイートの保護
ほぼ半数(48%)の組織が過去12ヶ月間にランサムウェア攻撃を経験しており、そのうちの半数以上(51%)がSaaSデータを標的としています。それでも、ほとんどの組織は200を超えるSaaSプログラムを使用し続けています。WasabiとHYCUによるウェビナー「Averting the SaaS Data Apocalypse(WasabiとHYCUでSaaSデータの崩壊を回避)」では、リスクを見極めてランサムウェアからSaaS環境を効果的に保護する方法をご紹介します。
Veeamが新たにリリースしたSoftware Applianceには、バックアップインフラにおける構築や保護の変化が反映されています。これにより、安全なデフォルト設定、自動パッチ適用、組み込みの不変性を備えた状態で、強化されたLinuxベースのバックアップシステムを導入できるようになりました。また、一貫性があり再現可能なプロセスでの管理も行えることで、運用効率とベースラインセキュリティが大幅に改善しました。しかし、レジリエンスは導入だけで完結するものではありません。Veeam Software ApplianceにWasabi Hot Cloud Storageを組み合わせることで、データセンターを超えた保護が実現します。つまり、安全で予測可能かつコスト効率が高い保護を、独立して管理されるクラウド層に拡張することができるようになりました。この重要性を理解するには、サイバーレジリエンスの真の意味、従来のバックアップとの違い、そしてサイバーレジリエンスが現在、効果的なデータ保護戦略の基準となっている理由などを踏まえて、基本に立ち返る必要があります。今、サイバーレジリエンスがなぜ重要なのかサイバーレジリエンスは、サイバーセキュリティの単なる言い換えではありません。これは、いかなる障害が発生した場合でもシステムの稼働とデータの信頼性を維持するためのより幅広い取り組みを指す用語です。また、サイバー攻撃、停電、ソフトウェアパッチの失敗、夜中の人為的な単純ミスなど、原因を問わず障害に耐え、迅速に復旧する能力を指します。そのため、サイバーレジリエンスは現代のデータ保護の指針として重視されています。Veeam Software Applianceは、ワークロードが実行される場所で一貫性があり安全な導入と自動パッチ適用を行い、レジリエンスを根本から強化します。Wasabiは、その保護をオフサイトへと拡張し、復旧用データを検証可能な状態で安全に保管します。これにより、攻撃だけでなく、現実世界で起こりうるあらゆるトラブルに備えた、完全なエンドツーエンドの戦略が構築されますVeeam Data...
最新の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ワークロードの実際の動作と適合させています。これにより、チームは技術的、運用的、そして経済的に長期にわたってスケールできるプラットフォームを構築できるようになります。...
これまで、欠けているパラメータ探しや古くなったAPIドキュメントの読解に苦労したことがあれば、質の悪いドキュメントがどれだけの時間を浪費することになるかをご存じのはずです。こういった状態は集中力の妨げとなるだけでなく、エラーの確認に追われ、機能を構築することができずにリリースが遅れる原因となります。そのため、WasabiではAPIファーストのアプローチを採用し、開発者向けのドキュメントとツールを根本から再構築しました。本稿では、新機能とその重要性、そして新しいWasabi API Reference Centerが開発のあらゆる側面を効率化する方法について解説します。より速く、よりスマートに、よりインタラクティブな体験をもたらすWasabi APIWasabiは、クラウドストレージを高速・予測可能・シンプルにすることを目指してきました。その使命を果たすうえで重要なのが、信頼性の高い統合を実現することです。そこで導入したのが、開発者がAPIを探索、テスト、展開する際に役立つインタラクティブな統合環境であるWasabi API Reference Center’(英語ページ)です。Wasabi API Reference...
