Oracle Cloud Infrastructure Object Storageによるストレージの最新化について
このソリューション・プレイブックは、ローカルまたはNFSファイルシステムからOracle Cloud Infrastructure Object Storage (OCI Object Storage)への長期ストレージの設計および移行の実行方法を理解するのに役立ちます。このようなソリューションは、コストを削減し、保存、ライフサイクル・ルールおよび事前認証済リクエストを追加機能として適用するのに役立ちます。
このソリューション・プレイブックでは、お客様事例を使用して、モダナイゼーションの取り組みを成功させるための出発点を強調しています。
オラクルでは、クラウドの移行と最新化について同じ会話の中で、利用可能なすべての方法、サービス、製品についてよくお話しします。会話には段階的なアプローチが必要となることが多く、データ・センター全体が体系的にクラウドに移行し、そのままリフト・アンド・シフトされ、それ以外のすべてがその後に続きます。
初期フェーズが完了すると、セキュリティ、監視、現在および進行中の統合の課題と比較して、アプリケーションの最新化の重要性が失われることがよくあります。また、インフラストラクチャ・チームが実行できる作業からアプリケーション・チームの作業への移行も強調しています。予算、タイミング、その他の優先事項が優先されるため、アプリケーションはそのままクラウドで実行されます。クラウドがもたらす真の潜在的コスト削減を実現するために、企業はコスト削減のためにオブジェクト・ストレージなどのテクノロジを検討する必要があります。
ファイル・アーカイブは、最小限の開発作業とテストでNFSからOCI Object Storageに移行できるため、始めるのに最適な場所です。このようなソリューションを実装すると、ユース・ケースに応じて、ストレージ上の10-50xの順序で節約できます。企業は、データ・センターの運用が責任をもつようになりつつあり、攻撃の可能性、サービスの損失および競合他社が絶えず革新する中で、目に見えない追加コストが発生する可能性があることに気付きました。
これにより、OCI Object Storageなどのクラウドネイティブ・サービスを優先的に使用して、コスト削減、ビジネスの保護、様々なワークロードをハイパースケーラで運用する負担の共有などを行う必要があります。
移行後の課題の理解
ここでの重要な点は、移行後の問題点に焦点を当て、影響力のあるアプリケーションを再設計することでしたが、1つの設計スプリント内で十分に取り組むことができるほど小さくなっています。このようにして、開発コストとテスト・コストを低く抑えながら、節約と安心を実現できます。
このソリューション・プレイブックのユースケースでは、共有ファイル・ストレージ(NFS)のコストがクラウドで問題になり、アプリケーションの元の設計が、それほど簡単に変更できない理由になりました。オンプレミスからクラウドへの移行プロジェクトにおいて、File Storageのより安価で信頼性の高い代替手段としてObject Storageについて、10xの節約についてペーパーでお話ししました。バックアップおよびレプリケーションを追加すると、10xが高くなる可能性があります。リージョン間レプリケーション、リテンション・ロック、ライフサイクル・ポリシーなどの効率的な機能はすべて連携して、重要なドキュメントを格納するコスト効率が高く信頼性が高く安全なシステムの基礎となるオブジェクト・ストレージにできます。ただし、アプリケーションがドキュメント・ストレージ用にNFSファイル・システムを中心に設計されており、POSIXセマンティクスが想定されている場合、事態は難しくなります。
このユース・ケースで最新化されたアプリケーションは、標準の3層アプリケーションですが、顧客請求を生成し、整理されたディレクトリ構造に転記し、ダウンロードおよび長期ストレージ用にカタログ化するために、調整されたCPU集中プロセスを実行する必要がある外部コンポーネントがいくつかあります。これらのPDFおよびその他のファイルは、生成されたパスでアクセスするために、非常に特定のファイル・ネーミング・パターンを持つ大規模なNFSファイル・システムに格納されました。しかし、Apache HTTPサーバーを中心に別のアプリケーションが構築され、このNFS共有の長期記憶域がそのドキュメント・ルートとして使用され、アプリケーションから生成されたURLを使用して、過去2年間の任意の時点からファイルをダウンロードできるようになりました。最後に、ある年齢より古いファイルをオンラインアーカイブから削除できますが、レコードを検索する監査者が要求することもできます。
したがって、NFSファイルシステムに10歳までのすべてのファイルを保持する必要がありました。基本的に、新しいファイルが生成されるたびにビジネスにより多くのコストがかかります。問題が複数の異なるアプリケーションに存在していたため、コストの問題は時間の経過とともに悪化することになります。
OCIオブジェクト・ストレージの活用
Object Storageは、頻繁に変更されないファイルに最適です。これは、使用が混在する共有ストレージに重点を置いたNFSとは対照的です。
OCI Object Storage Serviceのいくつかのオブジェクト・ストレージ設計要素と特定の機能を活用することで、可用性を高め、適切なワークロードのコストを削減できます。
このユースケースでは、中期アクセスおよび長期アーカイブ用に作成されたファイルが適しています。これらのファイルは1回書き込まれる可能性があり、変更せずに数か月または数年間保存する必要があります。実際、企業は、一定期間不変であることを保証したい場合があります。
全体的に、Object Storageがこれらのタイプのファイルに対して従来のファイル・ストレージよりも優れている主な理由を次に示します。
- 可用性: Object Storageはリージョン別サービスであり、単一のアベイラビリティ・ドメインに関連付けられていないことを意味します。
- 検索: オブジェクト・メタデータの使用は、ファイル名およびPOSIXスタイルの検索コマンドのみに依存するよりも有用です。
- 保持ルール: オブジェクトが書き込まれた後にバケット全体が変更されないようにすることで、即時のコンプライアンスを確保できます。
- ストレージ層: オブジェクト・ストレージの階層化(自動または手動)により、アクセス頻度が低い、またはビジネス・ルールに必要な保存オブジェクトのコストが大幅に削減されます。
- ライフサイクル・ポリシー: 保存後のストレージ層と自動削除(クリーンアップ)間の移動をチューニングすると、ストレージおよび管理が節約されます。
- レプリケーション: バケット全体を別のリージョンに簡単かつ自動的にレプリケートすると、可用性とデータへのアクセスが向上します。
- コスト: オブジェクト・ストレージを適切に構築および保守すると、NFSファイル・システムの複製や乱雑さが大幅に削減されます。
NFSは、マウントされた共有のPOSIXスタイルのファイルシステムを必要とするアプリケーションでも引き続き役立ちます。顧客は共有記憶域にNFSを必要としていましたが、その使用はアーカイブ・ファイルではなく、操作ファイルに制限されていました。ここで説明する解決策は、Object Storageの設定およびアクセス方法、および長期間のストレージ用に作成されたNFSストレージと新しいObject Storageアーカイブの両方を使用するようにアプリケーションを変更する方法について説明しています。
アーキテクチャ
このアーキテクチャは、長期ストレージをOCI Object Storageに移行する設計と実行を示しており、追加機能としてコストを削減し、保存、ライフサイクル・ルールおよび事前認証済リクエストを適用するのに役立ちます。
次のイメージは、アーキテクチャの「前」および「後」の実装を示しています。Oracle File System Service (FSS)は、大規模な共有ファイルシステムに使用されます。オンプレミス・データセンターから移行されたこのファイルシステムでは、アプリケーション・コンポーネントはバッチ処理を使用してアーカイブ・ファイルを継続的に生成します。したがって、同じNFSファイルシステムは、中間処理(スクリプト、一時ファイルなど) およびビジネス要件ごとに最大10年間維持する必要がある階層内に格納された実際のファイルアーカイブに必要なアプリケーション要素を保持します。
設定すると、OCI Object Storageバケットを使用して、NFSが実行していた内容のアーカイブ部分をホストします。バケットの読取りおよび書込みの権限は細かく定義され、大量のデータの流入に備えるために、保持およびライフサイクル・ルールが確立されます。アーカイブ・ファイルの大きな階層がOCI Object Storageにコピーされ、新しいオブジェクト・バケットに新しいアーカイブを配置するためにバッチ処理がリファクタされます。また、オブジェクト・ストレージからファイルにアクセスするために、アプリケーションやエンド・カスタマがこれらのアーカイブへのアクセス方法を変更する必要がないように、アクセス・メカニズムもわずかにリファクタリングされました。
次の図は、実装前のアーキテクチャを示しています。
oci-object-storage-modernization-arch-oracle1.zip
次の図は、実装後のアーキテクチャを示しています。
oci-object-storage-modernization-arch-oracle.zip
- テナンシ管理者- フル・アクセス
- アプリケーション管理者- オブジェクト読取りなしのアクセス制限
- 読取り専用- オブジェクト読取りなしのバケット検査
- 動的グループごとに追加されたステートメント
- 特定のリソースに対して限定的に定義
- インスタンスOCIDsのリスト
- インスタンス・コンパートメントOCID
- 3650日(10年)
- ロック済
e: ライフサイクル・ルール:
- 90日後- 頻度の低いストレージ
- 180日後- アーカイブ・ストレージ
- 3651日後- 削除
このアーキテクチャでは、次のコンポーネントがサポートされています。
- オブジェクト・ストレージ
Oracle Cloud Infrastructure Object Storageでは、データベースのバックアップ、分析データ、イメージやビデオなどのリッチ・コンテンツなど、あらゆるコンテンツ・タイプの構造化データおよび非構造化データにすばやくアクセスできます。インターネットから直接またはクラウド・プラットフォーム内から、安全かつセキュアにデータを格納し、取得できます。パフォーマンスやサービスの信頼性を低下させることなく、ストレージを拡張できます。迅速、即時、頻繁にアクセスする必要があるホット・ストレージには、標準ストレージを使用します。長期間保持し、ほとんどまたはほとんどアクセスしないコールド・ストレージには、アーカイブ・ストレージを使用します。
- ファイル・ストレージ
Oracle Cloud Infrastructure File Storageサービスは、永続的でスケーラブルなセキュアなエンタープライズ規模のネットワーク・ファイル・システムを提供します。File Storageサービスのファイル・システムには、VCN内のベア・メタル、仮想マシンまたはコンテナ・インスタンスから接続できます。また、Oracle Cloud Infrastructure FastConnectおよびIPSec VPNを使用して、VCN外からファイル・システムにアクセスすることもできます。
- アイデンティティおよびアクセス管理(IAM)
Oracle Cloud Infrastructure Identity and Access Management(IAM)は、Oracle Cloud Infrastructure(OCI)およびOracle Cloud Applicationsのアクセス・コントロール・プレーンです。IAM APIおよびユーザー・インタフェースを使用すると、アイデンティティ・ドメインおよびアイデンティティ・ドメイン内のリソースを管理できます。各OCI IAMアイデンティティ・ドメインは、スタンドアロンのアイデンティティおよびアクセス管理ソリューション、または異なるユーザー集団を表します。
アイデンティティ管理に関する考慮事項
プライベート・オブジェクト・ストレージ・バケットを使用することは、使用するための適切な権限を設定することを意味します。デフォルトでは、ユーザー・グループおよび動的グループには、通常、コンパートメントにスコープ指定されていないかぎり、object-familyなどの広範な権限セットへのアクセス権が付与されません。
このソリューションを導入する前に、オブジェクト・ストレージへのアクセスを許可するグループのみが権限を持っていることを確認する価値があります。ここで非常に役立つのは、アクセスの制限に関するCISランディング・ゾーンの方法に従うことです。このソリューションを実装する際には、動的グループの作成について説明するため、テナンシのコンパートメント構造とランディング・ゾーンで検討される概念の両方を理解する価値があります。また、動的グループおよびポリシー・ステートメントを絞り込む方法など、OCIポリシー構文についても読む価値があります。
RCLONEとOCIFSはどちらも認証メカニズムとして標準のOCI APIキーをサポートしていますが、認証するにはInstance Principalsと動的グループを選択しました。これにより、全体的なセキュリティ状態が向上します。キーの作成、配布またはローテーションは不要です。かわりに、動的グループごとに可能なかぎり狭い権限を確保するために、個別の動的グループが使用されます。たとえば、RCLONE動的グループのポリシーでバケットの作成を許可できますが、Apache動的グループではオブジェクト読取りのみが許可されます。
アーカイブ・ストレージに関する考慮事項
コストを節約し、OCI Object Storageの最低コスト層を利用するために、このソリューションはライフサイクル・ルールを実装しました。ライフサイクル・ルールは、オブジェクトを頻度の低い層に移動し、作成後しばらくしてアーカイブ層に移動します。
アーカイブされたオブジェクトは、標準層に直接再分類できません。アーカイブ済オブジェクト・ストレージはオフラインであるため、監査(ビジネス・プロセス)をリクエストできるプロセスを開発し、アーカイブから特定のファイルを取得してから、期限が切れた期間そのファイルにアクセスできるようにする必要があります。
再度、オブジェクト・ストレージの固有の機能を使用すると、ファイルを一時的にリコールし、一時的な場所(別のバケット)にコピーして、事前認証済リクエスト(PAR)を使用して外部に公開できます。これらは、バケット内の特定のファイルへのアクセスを許可する不明瞭なURL (不明瞭性によるセキュリティ)であり、一定時間後に失効し、アクセスを取り消すことができます。
リコール期間中に、ファイルを新しい標準層バケットにコピーしてから、自動的にアーカイブ・モードに戻すことができ、メンテナンスは必要ありません。RCLONEおよびOCI CLI、Java、RESTまたはPythonは、特定の監査バケットへのアクセス権を付与されたメイン・ソリューションにも同様に使用できます。