はじめに

今回から５回に分けて、Azure で Java アプリケーションを開発する際に現場で役立ちそうなポイントを、実装上のハマりどころなどを交えながらご紹介いたします。

第一弾のシナリオは、「Blob ストレージへのアップロード」です。

サンプルコードは以下に格納しています。

参考: 『kohei3110/JavaOnAzure-BlobStorage』

シナリオ概説

本シリーズでは、Blob Storage へのアップロードについて、Azure を使った Java アプリケーションのサンプルコードを使用しながら、開発方法をご紹介します。

一口に Blob アップロードといっても、あらゆる方式があるかと思います。

まず、クライアントから Blob をアップロードする場合、SAS を使ってアップロードする選択肢があります。サーバーを経由せず、Blob ストレージとクライアントのみの通信になるため、パフォーマンスが他の選択肢に比べてよいです。SPA からアップロードする場合は、まずは第一選択肢となるでしょう。

一方、クライアントにて SAS の使用が懸念される場合（例: SAS の流出を懸念する場合等）は、サーバーを経由してアップロードすることになります。サーバーを経由し、ストリームライクにアップロードする構成や、サーバーに一時的にファイルを保存し、あとでサーバーからアップロードする構成などが挙げられます。ただし、サーバーを経由するため、リソースや帯域を消費してしまうというデメリットが考えられます。

今回は、Blob アップロードのシナリオを、以下 4 つに区分しました。

No.	シナリオ	概要	記事 URL
1	サーバー経由でのストリームライクなアップロード	SAS の流出を懸念する場合、サーバー経由でのストリームライクなアップロード	Java on Azure 実践開発【Blob Upload ①: ストリームライクなアップロード編】
2	サーバーに一時保存後アップロード	アプリケーションサーバーのローカルストレージにファイルを一度保存後、アップロード（クライアントからは同期に見える）	Java on Azure 実践開発【Blob Upload ②: App Service ローカル保存後アップロード編】
3	サーバーに一時保存後定期アップロード	アプリケーションサーバーのローカルストレージにファイルを一度保存後、定期ジョブにてアップロード（クライアントからは非同期に見える）	Java on Azure 実践開発【Blob Upload ③: 定期アップロード編】
4	署名付き URL を使ったアップロード	アプリケーションから返却された署名付き URL を用いて、クライアントからファイルをアップロードする	Java on Azure 実践開発【Blob Upload ④: 署名付き URL を使ったアップロード編】

以下に、それぞれのシナリオを一枚絵にまとめました。

1. サーバー経由でのストリームライクなアップロード

Blob Storage へファイルをストリームライクにアップロードします。想定されるシナリオは、動画などの大きなファイルを、アプリケーション実行環境のローカルファイルストレージには保存せず、直接 Blob ストレージへストリームライクにアップロードする場合などです。

2. サーバーに一時保存後アップロード

アプリケーションサーバーのローカルファイルシステムにファイルを一時保存後、Blob アップロードします。クライアントからは同期的に見える構成です。一般的に、ローカルファイルシステムに依存する構成となり、スケール性に乏しいアーキテクチャとなります。

3. サーバーに一時保存後定期アップロード

アプリケーションサーバーのローカルファイルシステムにファイルを一時保存後、定期ジョブがBlob アップロードします。「2. サーバーに一時保存後アップロード」との違いは、クライアントからは非同期的に見える構成である点です。こちらも、一般的に、ローカルファイルシステムに依存する構成となり、スケール性に乏しいアーキテクチャとなります。

4. 署名付き URL を使ったアップロード

アプリケーションから返される署名付き URL を用いて、クライアントからファイルをストリームアップロードします。SPA では、こちらの構成で Blob アップロードをする場合が一般的です。

次回以降の記事では、上記４つのシナリオについて、サンプルコードを交えつつ、実装方法を解説していきます。

サンプルアプリケーション実行環境

App Service にアプリケーションをデプロイし、Blob Storage に対してファイルをアップロードする方式としています。シナリオ 3 「サーバーに一時保存後定期アップロード」で実行する定期ジョブは、Azure Web Jobs を使用しています。

Blob ストレージ

Azure Blob ストレージは、Azure で提供されているオブジェクトストレージです。大量の非構造化データを格納できるよう最適化されています。

例えば、画像データや動画データをストリーミングアップロードする場合や、アーカイブデータを格納する場合などのシナリオで使用されます。

Blob ストレージに Blob を格納するには、「コンテナ」という、ファイルシステムでいうディレクトリに似た概念のものを作成します。

本記事では詳細な説明を割愛するため、Blob ストレージの詳細は、 Docs をご参照ください。

Docs: 『Azure Blob Storage の概要』

App Service

App Service は、Windows、Linux、Docker コンテナ（カスタムコンテナー）の Web アプリケーションを Azure 上にホストすることができる PaaS です。

今回は、Java アプリケーションの実行環境として、App Service を作成しました。Java バージョンは 11 です。

本記事では詳細な説明を割愛するため、詳細は以下の Docs をご参照ください。

Docs: 『App Service のドキュメント』

Web Jobs

Web Jobs は、Azure App Serviceの機能のひとつとして用意されているイベント駆動のアプリケーションのプラットフォームです。本記事では詳細な説明を割愛するため、詳細は『3. 定期アップロード』の記事か、Docs をご参照ください。

Docs: 『Azure App Service で Web ジョブを使用してバックグラウンドタスクを実行する』

App Service Plan

App Service や Web Jobs、（オプションによっては）Azure Functions の実行環境です。後述する App Service や Web Jobs は、App Service Plan にマウントされたファイルシステムを参照します。

なお、今回は Web Jobs を実行するため、App Service Plan の OS は Windows を指定しています。
※ Linux では Web Jobs が実行不可のため。

サンプルコードアーキテクチャ

ここからは、サンプルとして作成したアプリケーションのアーキテクチャについて解説していきます。

サンプルアプリケーションはこちらに公開しています。

サンプル: 『kohei3110/JavaOnAzure-BlobStorage』

アプリケーションアーキテクチャ

レイヤードアーキテクチャを採用し、以下のように分割しています。

ディレクトリ	主な責務
`repository`	データアクセスなど、アプリケーションの外界とのやりとりを担当。
`service`	ビジネスロジックを担当。
`model`	データ構造を定義。
`Factory.java`	ファクトリクラス。インスタンス生成を担当。
`Controller.java`	コントローラクラス。リクエストのルーティングを担当。

UML 図は以下になります。

今回は、アノテーションを使わずコードを書きました。特定の DI コンテナに依存しない構成とする狙いがあります。

Controller.java にて受けたリクエストを、Service 層に流し、Service 層から Repository 層を call する形を採用しています。

Controller.java

    @PostMapping("/uploadstream")
    public ResponseEntity<String> uploadstream(@RequestBody MultipartFile multipartFile) throws Exception {
        try {
            UploadBlobStreamService uploadBlobStreamService = injectUploadBlobStreamService();
            uploadBlobStreamService.streamUpload(multipartFile);  // Service 層を call
            return ResponseEntity.status(HttpStatus.OK).body("upload succeeded");
        } catch (Exception e) {
            logger.warning(e.toString());
            throw new Exception("Upload operation has failed.");
        }
    }

Factory クラスにより、使用するインスタンスが生成されています。

Factory.java

    private BlobContainerClient blobContainerClient;

・・・

    public Factory(String containerName) {

・・・

        this.blobContainerClient = this.blobServiceClient
            .getBlobContainerClient(containerName);

・・・

    }

・・・

    public BlobContainerClient getBlobContainerClientInstance() {
        return this.blobContainerClient;
    }

・・・

環境変数

Blob Storage への接続文字列は、環境変数として定義し、アプリケーションから読み込むようにしています。デプロイの手間を減らし、環境ごとに適切な値を読み取るために、このような構成をとっています。

ローカルでお試しする際は、以下の環境変数をセットすることをお忘れなく。

env.sample.sh

export STORAGE_CONNECTION_STRING="DefaultEndpointsProtocol=https;BlobEndpoint=https://xxxxxxxxxxxxx.blob.core.windows.net/;AccountName=xxxxxxxxxxxxx;AccountKey=xxxxxxxxxxxxxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/xxx"
export FILE_LOCATION="C:\\hogehoge"

Java に関わらず、App Service 等 Azure 上のアプリケーション実行サービスでももちろん環境変数をセット可能です。

Azure Portal からは、以下の画面にて設定を確認できます。

詳細は、以下の Docs を参考にしてください。

Docs: 『App Service アプリを構成する』

Tips

こちらでは、構成上の Tips や注意点についてまとめます。

最大ファイルサイズ制限

今回の構成には当てはまりませんが、App Service の前に Application Gateway や Front Door を挟む構成の場合、アップロード可能なファイルの最大サイズに制限が出てきます。

本記事執筆時点では、以下の制限となっています。

App Service の前に配置するリソース	アップロード対象ファイルの最大サイズ
Application Gateway (Standard SKU)	V2 - 4 GB V1 - 2 GB
Application Gateway (WAF SKU)	V1 中規模 - 100 MB V1 大規模 - 500 MB V2 - 750 MB V2 (CRS 3.2 以降を使用) - 4 GB
Front Door	2GB

おわりに

本記事は、『Java on Azure 実践開発 Blob Upload 編】』の序章として、アプリケーション全体の構造や、今後の実装シナリオについてまとめました。

今後は、サンプルコードを交えつつ、Azure で Java アプリケーションを実行するための Tips をご紹介していきます！お楽しみに～。