ご注文はS3ですか？

「Amazon S3」はクラウドネイティブなオブジェクトストレージとして非常に幅広く使われています。S3互換を謳う様々なオブジェクトストレージサービス、オープンソースのプロジェクトも多く存在します。

AWSと競合するサービスもS3互換APIや乗り換え機能を提供しています。

個人的には「クラウドネイティブなオブジェクトストレージ＝S3」と言えるくらいに幅広いシーンで利用され、意識されていると考えています。こんなS3を「Azure Red Hat OpenShift」でも使いたいのです。

ただしAWSアカウントは一切作成せずに。

「Azure Red Hat OpenShift」はAROと略され、Microsoft AzureのManaged Serviceとして「Red Hat OpenShift」を利用できるソリューションです。もし自社のプライマリクラウドがAzureなのであれば、Auzreの利用料金と一緒に使った分だけの従量課金でOpenShiftを利用できるので、請求も含めて一元的に管理できます。加えて、Microsoft Entra ID（旧Azure Active Directory）との連携はもちろん、Azure OpenAI Serviceを含め、各種のAzure Serviceとの連携にはAROがバッチリハマるでしょう。

AROは、国内でも三菱重工や明治安田生命といった名高い企業さんで利用されているようです。

OpenShift Data Foundationを使う

OpenShift Data Foundation（略してODF）を使えば、OpenShift上でSoftoware Defined Storageを簡単に展開できます。OpenShiftのOperatorHubから「OpenShift Data Foundation Operator」をインストールし、カスタムリソースを作成すれば、ブロックボリューム、ファイルストレージ、オブジェクトストレージがStorageClassとして提供されます。

AROにおけるODFの利用は内部モード（クラスタ内ワークロードのためのSDS）として利用することができます。
https://access.redhat.com/articles/4731161

ODFはざっくり2つの要素から構成されています。

Rook-Ceph
Noobaa

Rook-Ceph は、Kubernetes上でオブジェクト、ブロック、ファイルストレージを提供できる統合ストレージシステムとして、スケーラブルで高可用性な分散ストレージが必要な場合に適しています。NooBaa は、S3互換APIを提供し、マルチクラウドやハイブリッドクラウド環境でオブジェクトストレージを柔軟に管理できるため、クラウドネイティブなS3ストレージが求められるケースに最適とされています。

今回の問「AROを使っているけどS3使いたい」を達成する為に、この「Noobaa」を使います。

やってみる

まずは「えいや！」でARO環境を用意しました。なお、本環境のOpenShiftのバージョンは「4.15.27」です。

OpenShiftにログインした後はいつものOpenShiftです。Azureだからどうという事はありません。ただし、StorageClassにはAzureのストレージが見えていますので、この辺はAzureに高度に統合されている感を感じます。

OperatorHubで「odf」と検索し、でODF Operatorをインストールします。

インストールが完了するとWebコンソールを更新するように通知が来ますので、更新してください。そうするとODF用のGUIが有効になります。なお、ODF Operatorが提供する各種のコンポーネントはNameSpace「openshift-storage」にDeployされ、トポロジー画面でも確認できます。今回の主役はこの中の「Noobaa Operator」です。

StorageSystemCRの作成が求められますので作成します。

通常ODFを利用する際にはフル機能が利用できる「Full deployment」が選択される場合がほとんどですが、もしオブジェクトストレージのみを利用したい場合は「MultiCloud Object Gateway」を選びます。

MultiCloud Object Gateway（MCG）についての詳細はRed Hatの宇都宮さんが公開してくださった資料を御覧ください。下手に私が説明するよりこれをお読み頂く方が、最もフィジカルで、最もプリミティブで、そして最もロジカルに理解させていただけます。
https://speakerdeck.com/tutsunom/data-federation-with-mcg

MCGを選んだら、自動的にバッキングストレージにプラットフォームに最適なStorageClassが選ばれています。今回はAzureがプラットフォームなので、先程StorageClass一覧で確認した「managed-csi」が選ばれますので、これ以降、そのままの設定で進めます。

最後に「StorageSystemの作成」をクリックすればNoobaaがDeployされるはずです。

トポロジー画面でNoobaaのDeploy状況を確認することができます。

Noobaa本体を提供するStatefulSet「noobaa-core」とバックエンドDBを提供するStatefulSet「noobaa-db-pg」、そしてS3 Endpointを提供するDeployment「noobaa-endopoint」です。

カスタムリソース「noobaa」のYAMLファイルも確認してみます。

noobaa.yaml

（中略）
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: cluster.ocs.openshift.io/openshift-storage
                operator: Exists
（中略）
  tolerations:
    - effect: NoSchedule
      key: node.ocs.openshift.io/storage
      operator: Equal
      value: 'true'

ODFをインストールするとNodeに自動的に振られるラベル「cluster.ocs.openshift.io/openshift-storage: ''」が存在するNodeに各コンポーネント（noobaa-core, noobaa-db-pg, noobaa-endopoint）をスケジュールする様に、nodeAffinityルールが設定されています。

「noobaa-endpoint」がまさに文字通り、S3のエンドポイントを提供してくれます。

クラスタ外部に対してはRoute、クラスタ内部に対してはServiceを宛先として提供します。この辺は非常にOpenShiftネイティブでわかりやすいですね。

ではさっそくバケットを作成します。バケットはカスタムリソースObjectBucketClaimを作成することで、指定したBucketClassからプロビジョニングされます。この辺の雰囲気は、「PersistentVolumeClaimを作成することで、指定したStorageClassから永続ボリュームPersistentVolumeがプロビジョニングされる流れ」と全く同様、相似形として理解できます。

すでにOpenShiftコンソール画面の「管理者向け表示」の左メニュー「ストレージ」から「Object Storage」が選択できるようになっています。

ここをクリックすると、NoobaaのDeployと共に利用できる様になったBucketClassが確認できます。タブ「オブジェクトバケット要求」に切り替えて、ObjectBucketClaimを作成します。なお、ObjectBucketClaimはPersistentVolumeClaimと同様、NameSpaceリソースです。なにかS3バケットを使いたいと思っているクライアントアプリケーションをDeployしているNameSpace（例：hogehoge）に切り替えてObjectBucketClaimを作成しましょう。

こんな感じでGUIで作成できます。

クラスタ内で利用できるStorageClassやBucketClassを選び、「作成」をクリックします。

できました。これでS3バケットにアクセスする際に必要な情報一式が払い出されます。ObjectBucketClaimによってバケットが作成されたことも確認できます。

さて、このアクセス情報一式を使って、AWS CLIからバケットにアクセスしてみます。

AWS CLIの設定

お使いのPCにAWS CLIをインストールし、AWSのアクセスキー・シークレットキーを設定します。ここで設定する情報は、今ObjectBucketClaimによって払い出されたものを指定します。

~ % aws configure                                                                      
AWS Access Key ID [***]: Access Key
AWS Secret Access Key [***]: Secret Key
Default region name [***]: us-east-1 
Default output format [json]:

リージョンは特になんでもお好きなものを指定してOKです。とりあえずus-east-1としておきました。ではAWSコマンドでS3（と完全互換のNoobaaによって作成された）バケットにアクセスしてみましょう。

aws s3 ls --endpoint-url <Routeから払い出されたURL>
2024-10-13 15:32:30 my-hogehoge-bucket-ca6219b8-aba2-43a8-a75a-29442dc1bd42
2024-10-13 15:32:30 first.bucket

おー！ObjectBucketClaim作成時に払い出された「Bucket Name」と同じバケットを認識できました。なにか適当なファイル（exaple.txt）について、バケット内にディレクトリ「my-first-directory」を作成し、その中にアップロードしてみます。

~ % aws s3 cp example.txt s3://<Bucket Name>/my-first-directory/example.txt --endpoint-url <Routeから払い出されたURL>

今作成・アップロードしたファイルをS3コマンドで確認します。

~ % aws s3 ls s3://my-hogehoge-bucket-ca6219b8-aba2-43a8-a75a-29442dc1bd42/ --endpoint-url https://s3-openshift-storage.apps.bm21j8xxb786a2add5.eastus.aroapp.io
                           PRE my-first-directory/
~ % aws s3 ls s3://my-hogehoge-bucket-ca6219b8-aba2-43a8-a75a-29442dc1bd42/my-first-directory/ --endpoint-url https://s3-openshift-storage.apps.bm21j8xxb786a2add5.eastus.aroapp.io
2024-10-13 15:37:47         12 example.txt

おわりに

クライアントアプリケーションからすると、Amazon S3を使っているのと全く同じ感覚で、ARO上に作成されたバケットにアクセスしたり操作できたりすることがわかりました。AWSが全く絡んでこないにもかかわらず、AWS CLIで操作できる点が非常に面白いですね。

AzureにもAmazon S3に該当するサービス「Azure Blob Storage」が存在しますが、普段Azureを触っていないアプリケーション開発者からすると、使い勝手の理解に際して認知不可が高いと思われます。私も正直普段全くAzureを触っていないので一から調べるのはしんどいです。

一方でOpenShiftを使っていると何かとオブジェクトストレージは必要です。

その点、「S3と全く同じ開発者体験ですよ」を謳えるNoobaa及びOpenShift Data Foundationは非常に有用な気がします。

ObjectBucketClaimを作成時、Access KeyとSecret KeyはObjectBucketClaimを作成したNameSpace内にSecretリソースとして作成されます。

Secretの中身をを見てみるとこんな感じです。

data:
  AWS_ACCESS_KEY_ID: <Access KeyをBASE64エンコードしたもの>
  AWS_SECRET_ACCESS_KEY: <Secret KeyをBASE64エンコードしたもの>

Access KeyとSecret Key、それぞれの値（Value）を参照するためのKeyが、それぞれAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYになっています。つまり、なんらかバケットにアクセス・操作したいクライアントアプリケーション側は、このSecretを参照すればよいということです。その際にはまるでAmazon S3を使うがごとく同Keyを指定すればよいということです。徹頭徹尾、「S3と全く同じ開発者体験ですよ」に即していますね。