EN
ホーム 記事一覧 ブック DH週間トピックス 検索 このサイトについて
English
ホーム » Tags

Amazon S3

Amazon S3オブジェクトストレージ

Cantaloupe IIIFサーバーのキャッシュ最適化で画像配信を最大7.6倍高速化した

Cantaloupe IIIFサーバーのキャッシュ最適化で画像配信を最大7.6倍高速化した

はじめに IIIFに対応した画像サーバーであるCantaloupeを、S3をソースとしたDocker環境で運用しています。IIIFビューア（Mirador, OpenSeadragonなど）では、ズームやパンの操作のたびに数十〜数百のタイルリクエストが同時に発生します。 今回、キャッシュ設定の見直しとパラメータチューニングにより、タイル配信速度を最大7.6倍高速化できたので、その手法と効果を共有します。 環境 サーバー: AWS EC2（2 vCPU, 7.6GB RAM） Cantaloupe: islandora/cantaloupe:2.0.10（Cantaloupe 5.0.7ベース） 画像ソース: Amazon S3（S3Source） テスト画像: 25167×12483px のTIFF画像（512×512タイル） リバースプロキシ: Traefik v3.2 構成: Docker Compose 問題：デフォルト設定ではキャッシュが無効 islandora/cantaloupe イメージのデフォルト設定を調査したところ、以下の状態でした。 キャッシュ種別 デフォルト 説明 Derivative Cache（加工済み画像） 無効 同じリクエストでも毎回画像変換が発生 Source Cache（元画像のローカルコピー） 有効（FilesystemCache） S3から取得した元画像をローカルに保持 Info Cache（画像メタデータ） 有効（メモリ内） 画像の寸法・タイル情報を保持 Client Cache（HTTPヘッダ） 有効（max-age 30日） ブラウザ側のキャッシュ制御 最大の問題は Derivative Cache が無効であることです。IIIFビューアが同じタイルを再度リクエストした場合でも、毎回 S3 → ダウンロード → 画像変換 → レスポンス という処理が走ります。 ベンチマーク方法 単純なタイル一括テスト まず基本的な性能測定として、以下の条件で一括タイルベンチマークを行いました。 タイル数: 91タイル（zoom level 4、scaleFactor=4の全タイル） 同時接続数: 10（ブラウザの一般的な同時接続数） ツール: curl + xargs -Pによる並列リクエスト # タイルURLを生成し、10並列で同時リクエスト xargs -a tile_urls.txt -P 10 -I {} \ curl -s -o /dev/null -w "%{time_total}\n" "{}" Miradorシミュレーション 単純なタイル一括テストに加え、IIIFビューア（Mirador）の実際の操作フローを再現したベンチマークも行いました。Miradorでは、ユーザーが画像を開くと以下のリクエストが短時間に発生します。 ...

2026年3月18日 · 2 分 · Nakamura
画像コレクション管理ツール 技術アーキテクチャ解説

画像コレクション管理ツール 技術アーキテクチャ解説

概要 以下の記事で、IIIFの機能を簡単に試すことを目的とした「画像コレクション管理」ツールについて紹介しました。 https://zenn.dev/nakamura196/articles/7d6bb4cdc414c4 今回は、このツールの裏側で使われている技術について紹介します。 はじめに 画像コレクション管理ツールは、画像コレクションを国際標準規格であるIIIF（International Image Interoperability Framework）形式で管理・公開するためのWebアプリケーションです。本記事では、このツールの技術的な実装について、特にIIIF仕様の実装と地理空間情報の扱いに焦点を当てて解説します。 技術スタック フロントエンド : Next.js 14 (App Router), React, TypeScript バックエンド : Next.js API Routes データストレージ : AWS S3互換オブジェクトストレージ（Cloudflare R2） 認証 : NextAuth.js 地図表示 : Leaflet, MapLibre GL JS IIIF ビューア : Mirador 3, OpenSeadragon IIIF実装の詳細 1. IIIF Presentation API v2/v3の両方をサポート 本ツールは、IIIF Presentation APIのバージョン2とバージョン3の両方に対応しています。これにより、様々なIIIFビューアとの互換性を確保しています。 v2とv3の主な違い // IIIF v2の構造 { "@context": "http://iiif.io/api/presentation/2/context.json", "@id": "https://example.com/manifest", "@type": "sc:Manifest", "label": "タイトル", "sequences": [{ "@type": "sc:Sequence", "canvases": [...] }] } // IIIF v3の構造 { "@context": "http://iiif.io/api/presentation/3/context.json", "id": "https://example.com/manifest", "type": "Manifest", "label": { "ja": ["タイトル"] }, "items": [...] // canvasの配列 } 2. マルチ言語対応 v3では、ラベルや説明文を言語別に管理できます： ...

2025年8月24日 · 更新: 2025年8月24日 · 3 分 · Nakamura
GakuNin RDMのストレージに、mdx.jpのオブジェクトストレージを追加する

GakuNin RDMのストレージに、mdx.jpのオブジェクトストレージを追加する

概要 GakuNin RDMのストレージに、mdx.jpのオブジェクトストレージを追加する方法です。 手順 mdx.jp mdx.jpのオブジェクトストレージの利用申請を行い、アクセスキーとシークレットキーを控えます。 GakuNin RDM S3 Compatible Storageを有効にします。 S3互換サービスとしてmdx S3DSを選択して、控えたアクセスキーとシークレットキーを入力します。 バケットの一覧が表示されるので、接続したいバケットを選択します。 結果として、「ファイル」メニューからアクセスできるストレージに、mdx.jpのオブジェクトストレージが追加されます。 今後、ドラッグ&ドロップにより、ファイルのアップロードなどを行うことができます。 まとめ GakuNin RDMとmdx.jpのオブジェクトストレージの接続にあたり、参考になりましたら幸いです。

2025年3月21日 · 更新: 2025年3月21日 · 1 分 · Nakamura
Omeka Sのファイルをmdx.jpのオブジェクトストレージに保存する

Omeka Sのファイルをmdx.jpのオブジェクトストレージに保存する

概要 Omeka Sのファイルをmdx.jpのオブジェクトストレージに保存する方法に関する備忘録です。 ベースとするモジュール Amazon S3との連携を可能にする以下のモジュールをベースとします。 https://omeka.org/s/modules/AmazonS3/ 本モジュールでは、Omeka Sで取り扱う画像や動画といったメディアのファイルをAmazon S3に保存するための拡張機能を提供します。 一方、endpointの指定ができないため、mdx.jpのオブジェクトストレージなどを対象にすることはできませんでした。 モジュールのカスタマイズ 上述した背景を踏まえて、Amazon S3以外のオブジェクトストレージを利用できるように、モジュールをカスタマイズしました。カスタマイズした結果は、以下のリポジトリで公開しています。 https://github.com/nakamura196/Omeka-S-module-AmazonS3 なお、カスタマイズについては、エディタとしてCursorを使用し、s3互換のオブジェクトストレージにも対応したいという依頼をclaude-3.7-sonnetに提出し、その結果を反映しています。 結果、上記のモジュールを使用することにより、Omeka Sで登録したメディアが以下のようなURLでアクセス可能になりました。 https://s3ds.mdx.jp/<バケット名>/large/3e0a78e1cbc239f37cfff0e777c40c2f9b2f5c92.jpg 以下は、filesディレクトリを、mdx.jpに接続したCyberduckで表示した例です。 モジュールの設定内容は以下のとおりです。カスタムエンドポイントURLという項目が追加されており、https://s3ds.mdx.jpを指定することで、mdx.jpのオブジェクトストレージを利用できるようになりました。 なお、上記の画面キャプチャで表示されているとおり、mdx.jpのオブジェクトストレージにファイルが保存される設定をしても、現時点ではWrong region. Please use region of a bucket:と表示されてしまいます。この点は、今後修正予定です。 モジュールのインストール 今回フォークして作成したカスタムモジュールをインストールするには、以下の手順を踏む必要があります。 cd <モジュールが格納されているディレクトリ> git clone https://github.com/nakamura196/Omeka-S-module-AmazonS3 AmazonS3 cd AmazonS3 composer install --no-dev Omeka Sにおいて、ソースからモジュールを使用するには、おおよそ共通して上記のような手続きが必要になります。 参考 Omeka Sのモジュールにおいて、同様の機能を提供するものとして、Any Cloudがあります。 https://github.com/HBLL-Collection-Development/omeka-s-any-cloud こちらもAmazon S3との接続機能を提供しており、またカスタイズを行う必要がなく、AWS Endpointを入力する項目が提供されていました。 ただ、これらの項目に先述したmdx.jpのオブジェクトストレージの情報を入力したところ、アイテムなどを登録する画面で以下のエラーが表示されました。 原因や対処方法については引き続き調査したいと思いますが、このエラーが遭遇したため、Any Cloudではなく、Amazon S3モジュールをカスタマイズする選択を行いました。 まとめ 2025年度からmdx.jpのオブジェクトストレージは無料で使用可能になるということで、デジタルアーカイブにおける公開画像の格納先や、また長期保存のためのストレージとしても有効な選択肢になるかと思います。 https://mdx.jp/mdx1/news/4839 デジタルアーカイブの構築や活用にあたり、参考になりましたら幸いです。

2025年3月7日 · 更新: 2025年3月7日 · 1 分 · Nakamura
mdx.jpのオブジェクトストレージとIIP Image（IIIF Image Server）を使ってIIIF画像を配信する

mdx.jpのオブジェクトストレージとIIP Image（IIIF Image Server）を使ってIIIF画像を配信する

概要 mdx.jpのオブジェクトストレージとIIP Image（IIIF Image Server）を使ってIIIF画像を配信する試行の備忘録です。 以下の記事の続きです。 Docker版IIP Image 以下で、IIPImage serverのDocker Imageが公開されていましたので、こちらを使います。 https://hub.docker.com/r/iipsrv/iipsrv 以下の記事などを参考に、Dockerをインストールします。 https://qiita.com/Marron-chan/items/570c7c7baaae3b4d6b11 実行 前回の記事に倣い、以下のようにmdx.jpのオブジェクトストレージをマウントします。 s3fs satoru196 ~/s3mount -o passwd_file=~/.passwd-s3fs -o url=https://s3ds.mdx.jp -o use_path_request_style -o allow_other 注意点として、前回の記事から、-o allow_otherを追加しています。これを追加しないと、次のコンテナ起動時に以下のエラーが発生しました。 docker: Error response from daemon: error while creating mount source path '~/s3mount/iip/images': mkdir ~/s3mount: file exists Run 'docker run --help' for more information -o allow_otherオプションを追加した上で、以下を実行します。無事に起動しました。 docker run -it -p 9000:9000 -p 8080:80 -v ~/s3mount/iip/images/:/images --rm iipsrv/iipsrv <-----------------------------------> Thu Mar 6 22:35:43 2025 IIPImage Server. Version 1.2 *** Ruven Pillay <ruven@users.sourceforge.net> *** Verbosity level set to 5 Running in standalone mode on socket: 0.0.0.0:9000 with backlog: 2048 Setting maximum image cache size to 10MB Setting filesystem prefix to '/images/' Setting filesystem suffix to '' Setting default JPEG quality to 75 Setting default PNG compression level to 1 Setting default WebP compression level to 50 Setting maximum CVT size to 5000 Setting HTTP Cache-Control header to 'max-age=86400' Setting 3D file sequence name pattern to '_pyr_' Setting default IIIF Image API version to 3 Setting Allow Upscaling to true Setting ICC profile embedding to true Setting up JPEG2000 support via OpenJPEG Setting image processing engine to CPU processor OpenMP enabled for parallelized image processing with 2 threads Setting URI mapping to iiif=>IIIF. Supported protocol: IIIF Memcached support enabled. Connected to servers: 'localhost' with timeout 86400 Initialisation Complete. <-----------------------------------> そして、今回の設定では、オブジェクトストレージの/satoru196/iip/imagesにtiled multi-resolution pyramid TIFFファイルを格納し、以下のようなURLでアクセスできることを確認します。 ...

2025年3月7日 · 更新: 2025年3月7日 · 2 分 · Nakamura
s3fs を使用してmdx.jpのオブジェクトストレージをファイルシステムのようにマウントする方法

s3fs を使用してmdx.jpのオブジェクトストレージをファイルシステムのようにマウントする方法

概要 s3fs を使用してmdx.jpのオブジェクトストレージをファイルシステムのようにマウントする機会がありましたので、備忘録です。 1. 事前準備 Ubuntu を対象とします。 ✅ s3fs のインストール sudo apt update sudo apt install s3fs ✅ 認証情報の設定 mdx.jpのオブジェクトストレージの アクセスキー と シークレットキー を ~/.passwd-s3fs に保存。 echo “ACCESS_KEY:SECRET_KEY” > ~/.passwd-s3fs chmod 600 ~/.passwd-s3fs # セキュリティのため権限変更 2. S3 ストレージをローカルにマウント ✅ マウントポイントを作成 mkdir ~/s3mount ✅ s3fs でマウント s3fs your-bucket /s3mount -o passwd_file=/.passwd-s3fs -o url=https://s3ds.mdx.jp -o use_path_request_style オプションの説明 • -o passwd_file=~/.passwd-s3fs → 認証情報を指定 • -o url=https://s3ds.mdx.jp → オブジェクトストレージのエンドポイント • -o use_path_request_style → MinIO や Ceph のような “パススタイル” の S3 互換ストレージで必要 ...

2025年3月6日 · 更新: 2025年3月6日 · 1 分 · Nakamura
mdx.jpのオブジェクトストレージに保存したIIIFマニフェストファイルをNestJSから利用する

mdx.jpのオブジェクトストレージに保存したIIIFマニフェストファイルをNestJSから利用する

概要 mdx.jpのオブジェクトストレージに保存したIIIFマニフェストファイルをNestJSから利用する機会がありましたので、備忘録です。 背景 mdx.jpのオブジェクトストレージに関して、簡単に確認したところ、corsの設定ができず、mdx.jpのオブジェクトストレージにアップロードしたIIIFマニフェストファイルを他のビューアから利用することは難しいようでした。 https://tech.ldas.jp/ja/posts/ad76f58db4e098/#注意（corsの許可） そこで、NestJSからオブジェクトストレージにアップロードしたIIIFマニフェストファイルをロードして返却します。 ソースコード 以下のリポジトリからご確認いただけます。 https://github.com/nakamura196/nestjs-iiif 以下のような環境変数を用意します。mdx.jpのオブジェクトストレージを使用するため、S3_ENDPOINTにhttps://s3ds.mdx.jpを与えます。 S3_ENDPOINT=https://s3ds.mdx.jp S3_REGION=us-east-1 S3_ACCESS_KEY_ID=xxx S3_SECRET_ACCESS_KEY=xxx S3_BUCKET_NAME=xxx そして、@aws-sdk/client-s3を利用して、以下のように、オブジェクトストレージ上のIIIFマニフェストファイルをダウンロードして返却します。 // src/s3.service.ts import { Injectable } from '@nestjs/common'; import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3'; import { Readable } from 'stream'; import * as dotenv from 'dotenv'; dotenv.config(); @Injectable() export class S3Service { private readonly s3Client: S3Client; constructor() { this.s3Client = new S3Client({ region: process.env.S3_REGION, endpoint: process.env.S3_ENDPOINT, forcePathStyle: true, // パススタイルを有効化（多くの互換ストレージで必要） credentials: { accessKeyId: process.env.S3_ACCESS_KEY_ID, secretAccessKey: process.env.S3_SECRET_ACCESS_KEY, }, }); } async getJsonFile(key: string): Promise<any> { const bucket = process.env.S3_BUCKET_NAME; if (!bucket) { throw new Error('S3_BUCKET_NAME is not set in environment variables.'); } const command = new GetObjectCommand({ Bucket: bucket, Key: key }); const response = await this.s3Client.send(command); const stream = response.Body as Readable; const chunks: Uint8Array[] = []; for await (const chunk of stream) { chunks.push(chunk); } const fileContent = Buffer.concat(chunks).toString('utf-8'); return JSON.parse(fileContent); } } まとめ mdx.jpのオブジェクトストレージに保存したIIIFマニフェストファイルの利用にあたり、参考になりましたら幸いです。

2024年12月1日 · 更新: 2024年12月1日 · 1 分 · Nakamura
Archivematicaのtransferにおいて、processing_configを使う

Archivematicaのtransferにおいて、processing_configを使う

概要 Archivematicaのtransferにおいて、processing_configの使用方法について説明します。 背景 Archivematicaのtransferにおいて、processing_configを選択することができます。以下では、「automated」「default」「mdx」の3つから選択できることがわかります。 これは、「Administration」メニューにおける「Processing configuration」において設定することができます。 例えば以下は、mdx.jpのs3互換ストレージとやりとりすることを前提とした設定例です。 以下のように、「Store AIP location」に対象ストレージを選択することで、このprocessing configurationを選択した際には、当該ストレージにAIPが保存されることになります。 APIからの利用 APIからもこの設定を利用することができます。 以下のBETA版として提供されているものになりますが、/api/v2beta/packageを利用することができます。 https://www.archivematica.org/en/docs/archivematica-1.16/dev-manual/api/api-reference-archivematica/#package processing_configオプションを設定することで、APIからの利用においても、入力データごとに、AIPやDIPの出力フォルダを変更することができます。 まとめ Archivematicaの利用にあたり、参考になりましたら幸いです。

2024年11月19日 · 更新: 2024年11月19日 · 1 分 · Nakamura
Archivematicaにmdx.jpのオブジェクトストレージを追加する

Archivematicaにmdx.jpのオブジェクトストレージを追加する

概要 Archivematicaにmdx.jpのオブジェクトストレージを追加する機会がありましたので、備忘録です。 背景 以下の記事で、Amazon S3をArchivematicaの処理対象およびAIPの保存先に設定する方法を記載しました。 今回は、この手順をベースとしつつ、mdx.jpのオブジェクトストレージを接続してみます。 設定方法 以下のように設定します。 S3 Endpoint URLには、https://s3ds.mdx.jpを設定します。 Access Key ID to authenticateとSecret Access Key to authenticate withには、以下で得られるアクセスキーと秘密鍵を使用します。 結果 結果、以下のように、mdx.jpのオブジェクトストレージを入出力ストレージとして利用できるようになりました。これにより、AIPやDIPをmdx.jpのオブジェクトストレージに保存することができます。 補足 以下の記事で記載した方法を参考に、GakuNin RDMとmdx.jpのオブジェクトストレージを接続することができます。 これにより、GakuNin RDM上でAIPやDIPの確認が可能となります。これにより、GakuNin RDMのBinderHubを用いたAIPの分析や可視化が可能となります。 可視化例として、ArchivematicaのMETSファイルを人間に優しい方法で探索可能とするMETSFlaskの応用などが考えられます。 まとめ Archivematica, GakuNin RDM, mdx.jpなどの連携にあたり、参考になりましたら幸いです。

2024年10月25日 · 更新: 2024年10月25日 · 1 分 · Nakamura
GakuNin RDMとAmazon S3を接続し、Archivematicaでファイルを処理する

GakuNin RDMとAmazon S3を接続し、Archivematicaでファイルを処理する

概要 GakuNin RDMとAmazon S3を接続し、Archivematicaでファイルを処理する方法に関する備忘録です。 https://rcos.nii.ac.jp/service/rdm/ 背景 以下の記事で、ArchivematicaでAmazon S3を処理対象とする方法を記載しました。 これにより、指定したバケットにファイルやフォルダをアップロードすることにより、それらをArchivematicaの処理対象として、AIPやDIPを作成することができます。 ただし、このままではプロジェクトのメンバー毎にIAMユーザを作成する必要がありました。 GakuNin RDMの利用 今回はメンバー全員がGakuNin RDMのプロジェクトのメンバーとして登録されていました。 そこで、プロジェクトにAmazon S3を接続して、GakuNin RDMからS3にファイルをアップロードできるようにしてみます。 これにより、IAMユーザの管理が不要になります。 設定方法 アドオンを選択します。 Amazon S3を有効にします。 IAMユーザで作成したアクセスキーIDとシークレットアクセスキーを入力することで、バケットの一覧が表示されます。 結果、GakuNin RDMからAmazon S3にファイルをアップロードできるようになりました。 Archivematicaからも同バケットを以下のように参照できるため、ここからAIPなどを作成することができます。 まとめ GakuNin RDMを利用可能な方に限られてしまいますが、参考になりましたら幸いです。

2024年10月9日 · 更新: 2024年10月9日 · 1 分 · Nakamura
[2024年版] AWSサーバーレスアプリケーションによるIIIF Image Serverの構築

[2024年版] AWSサーバーレスアプリケーションによるIIIF Image Serverの構築

概要 AWSサーバーレスアプリケーションによるIIIF Image Serverの構築に関する2024年度版の記事です。 背景 以下で、serverless-iiifというリポジトリが公開されています。本リポジトリを用いることにより、AWSのサービスを用いて、コスト効率が高く、無限にスケーラブルなIIIF Image Serverを構築することができると謳われています。 https://github.com/samvera/serverless-iiif 以下で、2022年時点の使い方を紹介しましたが、今日のサービスはより使いやすいものになっていました。 方法 いくつか構築方法がありますが、GUIを通じた構築方法として、以下を参考にします。基本的な構築については、以下のサイトの通り行います。ここでは、CloudFrontとRoute 53によるカスタムドメインの設定を含む手順について紹介します。 Lambdaの作成 https://samvera.github.io/serverless-iiif/docs/quick-start/deployment-sam まず、以下にアクセスします。 https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-1:625046682746:applications/serverless-iiif カスタムドメインによる配信にあたり、いくつかの設定を行います。 まず、ForceHostの項目に、設定したいカスタムドメイン名を入力します。 さらに、SourceBucketにバケット名を入力します。以下の例ではたまたまカスタムドメインと同じ名前の例ですが、任意のバケット名を入力します。 最後に、「このアプリがカスタム IAM ロールを作成することを承認します。」にチェックを入れて、「デプロイ」ボタンを押します。 その後に遷移する以下のような画面において、「デプロイ」タブを選択して、「CloudFormation スタック」のリンクをクリックします。 「出力」タブに遷移すると、v2やv3のエンドポイントが確認できます。 tiled TIFFsの作成 以下のページなどを参考に、tiled TIFFsファイルを作成します。 https://samvera.github.io/serverless-iiif/docs/source-images または、「『石見国絵図』,写,〔江戸中期〕. 国立国会図書館デジタルコレクション 」の画像をtile TIFFsに変換したファイルを以下から取得いただけます。サンプルデータとしてお使いください。 https://github.com/nakamura196/iiif-sampledata/raw/main/1286204.tif このファイルを先に指定したAmazon S3のバケットにアップロードすると、以下のようなURLでImage APIにアクセスすることができます。 https://istxbnjtm5x7qcpkwapsznyltm0sufnb.lambda-url.us-east-1.on.aws/iiif/3/1286204/info.json 注意点として、上記の結果得られるJSONファイルのidには、https://iiif.aws.ldas.jp/iiif/3/1286204という値が指定されています。 これは、先の設定で、ForceHostに指定した値が反映されています。 なお、画像の閲覧には、神崎正英氏が作成されているImage Annotatorが便利です。以下のように、uパラメータでURLを指定すると、画像を表示することができます。 https://www.kanzaki.com/works/2016/pub/image-annotator?u=https://istxbnjtm5x7qcpkwapsznyltm0sufnb.lambda-url.us-east-1.on.aws/iiif/3/1286204/info.json カスタムドメインの設定 最後にカスタムドメインの設定を行います。 まず、CloudFrontでディストリビューションを作成します。Origin domainには、先ほどアクセスしたURLのon.awsで終わるところまでを入力します。 そして、「代替ドメイン名 (CNAME)」の箇所において、設定したいドメイン名を入力します。合わせて、「Custom SSL certificate」も設定します。 上記でCloudFrontの設定は完了です。 最後に、Route 53でCloudFrontディストリビューションへの設定を行います。 結果、以下のURLからJSONファイルを取得することができます。 https://iiif.aws.ldas.jp/iiif/3/1286204/info.json まとめ 誤っている点もあるかもしれませんが、AWSサーバーレスアプリケーションによるIIIF Image Serverの構築にあたり、参考になりましたら幸いです。 ...

2024年9月9日 · 更新: 2024年9月9日 · 1 分 · Nakamura
mdx.jpのオブジェクトストレージに複数ファイルをアップロードする

mdx.jpのオブジェクトストレージに複数ファイルをアップロードする

概要 mdx.jpのオブジェクトストレージに複数ファイルをアップロードする方法の備忘録です。以下の動画を参考にしています。 https://youtu.be/IN_4NS9hO2Y 準備 macOSで作業します。 brew install s3cmd 設定（内容は動画を確認してください。） s3cmd --configure 一括登録（同期） 以下は、ローカルのrekionフォルダ内のファイルをs3://rekion/iiif/と同期します。 s3cmd sync docs/rekion/ s3://rekion/iiif/ --exclude '.DS_Store' 参考 find . -name '.DS_Store' -type f -delete aclの一括変更 s3cmd setacl s3://rekion/iiif/ --acl-public --recursive 注意（corsの許可） 以下のxmlファイルを用意して、corsの許可を試みました。 <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <CORSRule> <AllowedOrigin>*</AllowedOrigin> <AllowedMethod>GET</AllowedMethod> <AllowedHeader>*</AllowedHeader> </CORSRule> </CORSConfiguration> ただし、以下の結果となり、この方法ではcorsの許可ができませんでした。 s3cmd setcors cors.xml s3://rekion/ ERROR: S3 error: 501 (NotImplemented): A header or parameter you provided implies functionality that is not implemented. 設定方法について、引き続き調べたいと思います。 まとめ mdx.jpのオブジェクトストレージの利用にあたり、参考になりましたら幸いです。

2024年7月9日 · 更新: 2024年7月9日 · 1 分 · Nakamura
mdx.jpのオブジェクトストレージとCantaloupe Image Serverを使ってIIIF画像を配信する

mdx.jpのオブジェクトストレージとCantaloupe Image Serverを使ってIIIF画像を配信する

概要 mdx.jpのオブジェクトストレージとIIIFイメージサーバの一つであるCantaloupe Image Serverを使ってIIIF画像を配信する方法に関する備忘録です。 背景 以下の記事で、mdx.jpのオブジェクトストレージを使った画像の配信方法について紹介しました。 また以下の記事で、Cantaloupe Image Serverで、Amazon S3に格納した画像を配信する方法について紹介しました。 これらを組み合わせることにより、デジタルアーカイブにおけるIIIF画像配信コストの課題の解決を目指します。 方法 以下の記事で紹介したDocker版Cantaloupeを使用します。 以下のリポジトリから、ソースコードをダウンロードいただけます。 https://github.com/nakamura196/docker_cantaloupe_s3 同梱されている.env.sampleを.envファイルにリネームし、設定を変更します。 # aws s3 CANTALOUPE_S3SOURCE_ENDPOINT= # mdx.jp # CANTALOUPE_S3SOURCE_ENDPOINT=https://s3ds.mdx.jp CANTALOUPE_S3SOURCE_ACCESS_KEY_ID= CANTALOUPE_S3SOURCE_SECRET_KEY= CANTALOUPE_S3SOURCE_REGION= CANTALOUPE_S3SOURCE_BASICLOOKUPSTRATEGY_BUCKET_NAME= ポイントはCANTALOUPE_S3SOURCE_ENDPOINTです。ここに、https://s3ds.mdx.jpを与えて、取得したACCESS_KEY_IDやSECRET_KEY、作成したBUCKET_NAMEやREGIONを設定します。 デモ 冒頭の記事でも使用した、いらすとやさんの画像を利用します。 https://www.irasutoya.com/2016/09/blog-post_810.html 以下、上記でアップロードした同じ画像ファイルを、Cantaloupeを使って配信している例です。 info.json https://cantaloupe.aws.ldas.jp/iiif/3/baby_asia_boy.png/info.json グレー化: full/max/0/gray.jpg https://cantaloupe.aws.ldas.jp/iiif/3/baby_asia_boy.png/full/max/0/gray.jpg なお、Cantaloupeを使って画像配信を行う場合には、上記の記事で実施したACLの設定（EveryoneにRead権限を与える）は不要です。デフォルトの設定を使用することで、オブジェクトストレージ上の画像ファイルへの直接アクセスは不可としつつ、Cantaloupeを介したアクセスのみを許可できるかと思います。 以下の記事で紹介したようなCantaloupe側のAccess Control設定を組み合わせることで、アクセス制御を実現することになるかと思います。 まとめ Amazon S3に格納した画像をIIIF画像として配信する方法として、以下の方法もあります。これが、Amazon S3以外のオブジェクトストレージにも対応しているのか、今後調査してみたいと思います。 IIIF画像の配信にあたり、参考になりましたら幸いです。

2024年7月7日 · 更新: 2024年7月7日 · 1 分 · Nakamura
mdxのオブジェクトストレージを使用する（Cyberduckの利用）

mdxのオブジェクトストレージを使用する（Cyberduckの利用）

概要 mdxのオブジェクトストレージを使用する機会がありましたので、備忘録です。 https://mdx.jp/ 料金 2024年度の料金は以下のようになっています。 https://mdx.jp/guide/charge 1GBあたり、0.01ポイント（円）/日となっており、おおよそ1GBあたり、0.3円/月となっています。 申請方法 & s3cmdを用いた使い方 以下の公式チュートリアル動画が参考になりました。 https://www.youtube.com/watch?v=IN_4NS9hO2Y Cyberduckを使う 上記の動画ではコマンドラインツールによるファイル操作方法が紹介されています。 ここでは、Cyberduckを使用して、GUIを使ってファイル操作を行います。 AWS S3に対するCyberduckの操作方法を以下の記事で紹介しています。以下の方法を参考に、mdxのオブジェクトストレージに接続してみます。 接続設定 「新規接続」から接続設定を行います。 「Amazon S3」を選択して、サーバに「s3ds.mdx.jp」を入力します。 そして、発行された「アクセスキーID」および「シークレットアクセスキー」を入力します。 バケットの作成 右クリック > 「新規フォルダ」でバケットを作成できます。 ファイルのアップロード 以下のいらすとやさんの画像を使用します。 https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNuMuIaXnIW5QJXkLiV1ojUeUiIwNQF1O0lp2LgG2LGJUbIU8j4bFAyLyKq3BiYp53p0Yc8AtMsEykJAQgEx4SJyFvKY4OyNeDBFopPb4lnV7_wtZNkr91qwj6-m-8s-sl1aadYMhrpuoI/s800/baby_asia_boy.png 「satoru196」フォルダにドラッグ＆ドロップでアップロードすることができます。 上述した公式チュートリアルでも言及されていますが、このままでは以下のURLにアクセスしても、表示ができません。 https://s3ds.mdx.jp/satoru196/baby_asia_boy.png 以下のようなエラーコードが表示されます。 <Error> <script/> <Code>AccessDenied</Code> <Message>Access Denied</Message> <RequestId>...</RequestId> <HostId>00000000000000000</HostId> </Error> ACLの変更 ファイルを右クリックして、「情報」をクリックします。 以下のように、Everyoneを選択して、 READ権限を付与します。 この結果、以下のURLから画像を閲覧することができます。 https://s3ds.mdx.jp/satoru196/baby_asia_boy.png まとめ mdxのオブジェクトストレージを活用することで、様々な用途がありますが、例えばメディアを安価に公開することができそうです。特に、デジタルアーカイブにおけるメディアの公開元として、有力なインフラになり得るかと思います。 mdxのs3互換のオブジェクトストレージの利用にあたり、参考になりましたら幸いです。

2024年7月6日 · 更新: 2024年7月6日 · 1 分 · Nakamura
Amazon S3とRoute 53を使ってリダイレクトする

Amazon S3とRoute 53を使ってリダイレクトする

概要 あるURLから他のURLにリダイレクトさせる必要があり、Amazon S3とRoute 53を使用して実現することができたので、備忘録です。 方法 この方法では、S3バケットを使ってリダイレクトを行い、DNS設定にはRoute 53を使用します。以下にその手順を説明します。 ステップ1: Amazon S3バケットの設定 Amazon S3で新しいバケットを作成します。バケット名はリダイレクトさせたいドメイン名と一致させます（例：example.com）。 バケットのプロパティで「静的ウェブサイトホスティング」を選択します。 「静的ウェブサイトホスティング」のオプションで、「リダイレクト要求」を選び、リダイレクト先のURL（http://example.net など）を入力します。 ステップ2: Route 53でのDNS設定 Route 53で、リダイレクトするドメイン名のホストゾーンを開きます。 新しいレコードセットを作成します。レコードのタイプは A を選択します。 「エイリアス」を「はい」に設定します。 エイリアスターゲットとして、ステップ1で設定したS3バケットの静的ウェブサイトホスティングのエンドポイントを選択します（例：example.com.s3-website-us-east-1.amazonaws.com）。 これで、指定したドメインにアクセスがあった場合、設定したURLにリダイレクトされるようになります。この方法は、簡単でありながら効果的にドメインから別のURLへのリダイレクトを実現することができます。 まとめ 参考になりましたら幸いです。

2024年7月3日 · 更新: 2024年7月3日 · 1 分 · Nakamura
StrapiでCSPのエラーが発生した際の対処法

StrapiでCSPのエラーが発生した際の対処法

概要 Strapiと以下のプラグインを使って、メディアをS3に格納する構成としました。 https://www.npmjs.com/package/@liashchynskyi/strapi-provider-upload-s3-cloudfront その際、以下のエラーが発生し、画像が表示されませんでした。 Refused to load the image 'https://xxx/uploads/yyy.jpg' because it violates the following Content Security Policy directive: "img-src 'self' data: blob: dl.airtable.com". この課題に対して、以下の記事で述べられている通り、./config/middleware.jsを修正することで、この問題を解決することができました。 https://zenn.dev/studiobros/articles/04400f413eb2aa ACLについても 同様に、S3にメディアをアップロードできない状態にも遭遇しましたが、上記の記事にある通り、S3のACLを有効にし、さらに適切なブロックパブリックアクセス (バケット設定)を設定することで、無事にアップロードできるようになりました。 まとめ StrapiとS3を組み合わせたヘッドレスCMSの構築にあたり、参考になりましたら幸いです。

2024年6月12日 · 更新: 2024年6月12日 · 1 分 · Nakamura
AWS CLIを使用したS3バケットの一括削除

AWS CLIを使用したS3バケットの一括削除

AWS CLIを使用してS3バケットの一覧を取得し、特定のパターンに基づいてバケットを削除するには、以下の手順を実行できます。ここでは、wbyという文字列で始まるバケットを削除する方法について説明します。 必要なもの AWS CLIがインストールされていること。 適切なAWSの認証情報とアクセス権限が設定されていること。 ステップ 1: バケットの一覧を取得 まず、インストールされているAWS CLIを使用して、すべてのS3バケットの一覧を取得します。 aws s3 ls ステップ 2: 条件に一致するバケットの削除 wbyで始まるバケットを削除するには、シェルスクリプトを利用して条件に一致するバケットをフィルタリングし、それらを削除します。 以下のスクリプトは、wbyで始まるバケット名を検索し、各バケットを削除します。注意：このスクリプトはバケットとその中のすべてのオブジェクトを削除します。実行前にデータのバックアップを確認してください。 aws s3 ls | awk '{print $3}' | grep '^wby' | while read bucket do echo "Deleting bucket $bucket..." aws s3 rb s3://$bucket --force done このスクリプトは次のことを行います： aws s3 lsでバケット一覧を取得。 awk '{print $3}'でバケット名のみを抽出。 grep '^wby'でwbyで始まるバケット名をフィルタリング。 while read bucketループで各バケットを削除。 注意 バケットを削除する前に、必要なデータがバックアップされていることを確認してください。 バケットが空でない場合、aws s3 rb --forceオプションを使用してバケットとその中のすべてのオブジェクトを削除します。 実行する前に、削除されるバケット名を確認するために、実際に削除するコマンドを実行する前にechoステートメントを挟むことをお勧めします。

2024年4月26日 · 更新: 2024年4月26日 · 1 分 · Nakamura
ArchivematicaでAmazon S3を処理対象およびAIPの保存先に設定する

ArchivematicaでAmazon S3を処理対象およびAIPの保存先に設定する

概要 Archivematicaにおいて、Amazon S3上のファイルやフォルダを処理対象として、さらに処理結果であるAIPをS3に保存する方法に関する備忘録です。 S3をストレージとして利用することにより、他のシステムとの連携の容易化や、AIPの長期保存に関する選択肢が増えると考えられます。 ウェルカムコレクションの以下の記事が参考になりました。 https://docs.wellcomecollection.org/archivematica/administering-archivematica/bootstrapping Amazon S3の設定 バケットを作成します。今回、us-east-1リージョンに、archivematica.aws.ldas.jpというバケットを作成しました。 そして処理対象のファイルなどを格納する「transfer_source」、処理結果であるAIPを格納する「aip_storage」というフォルダを作成しておきます。これらの名前や階層は任意で、後述の過程でどのフォルダを使用するか設定できます。 Archivematica Storage Serviceの設定 Dockerを使ってArchivematicaをインストールした場合、以下のようなURLでArchivematica Storage Serviceにアクセスできます。 http://127.0.0.1:62081/ ログイン後、以下にアクセスします。「Create new space」リンクをクリックします。 /spaces/ 「Create Space」の画面で、以下のように入力します。「Access protocol」にS3を選択し、Access Keyなどを入力します。 Staging pathについてはよくわからず、以下の記事の値を入力します。 https://docs.wellcomecollection.org/archivematica/administering-archivematica/bootstrapping#step_7 Spaceを作成後、「Create Location here」を押して、ロケーションを作成します。2つリンクがありますが、どちらも同じでした。 ここで、2つのロケーションを作成します。一つは、以下のような、Purposeを「Transfer Source」とするロケーションです。 Relative Pathについては、「Browse」ボタンから、先に作成したフォルダから選択します。 また上記ではPipelineがひとつですが、複数のPipelineを作成している場合には、関連づけるものを選択することになると思います。 もう一つは、以下のような、Purposeを「AIP Storage」とするロケーションです。 それぞれの画面で、「Set as global default location for its purpose:」という項目がありますが、これをチェックしておくと、後述するデフォルト設定などが不要になります。 確認 ここまでの設定により、/spaces/にアクセスすると、デフォルトのAccess Protocolが「Local Filesystem」のスペースに加えて、Access Protocolが「S3」のスペースが追加されていることが確認できます。 さらに、/locations/にアクセスすると、追加した2つのロケーションが追加されていることが確認できます。 Archivematica Dashboardの設定 Dockerを使ってArchivematicaをインストールした場合、以下のようなURLでArchivematica Dashboardにアクセスできます。 http://127.0.0.1:62080/ AIPの格納先の設定 そして以下にアクセスして、例えばプロセスautomatedを編集します。 /administration/processing/ ...

2024年2月3日 · 更新: 2024年2月3日 · 1 分 · Nakamura
Docker版Cantaloupeを使用して、S3バケットにアクセスしSSL通信を行う方法

Docker版Cantaloupeを使用して、S3バケットにアクセスしSSL通信を行う方法

概要 Docker版のCantaloupeの使い方を以下で紹介しました。 このDocker版Cantaloupeを（大規模ではない）production環境で使用するには、Amazon S3との接続や、SSL対応が求められます。その方法を一例を紹介します。 Amazon S3との接続 公式では以下で紹介されています。 https://cantaloupe-project.github.io/manual/5.0/sources.html#S3Source 日本語の記事として以下があります。 また、今回扱うDocker版では、以下に記載がありました。 https://github.com/Islandora-Devops/isle-buildkit/blob/main/cantaloupe/README.md#settings そこで、S3と最低限の接続を行うためのリポジトリを作成しました。 https://github.com/nakamura196/docker_cantaloupe_s3 .env.exampleを.envにリネームまたはコピーして、必要な値を入力します。 SSL対応 以下の記事を参考にしました。EC2上にDockerをインストールし、nginx-proxyとnginx-proxy-lets-encryptを利用してSSL化を行いました。 https://qiita.com/atsuya/items/7cb6e0ccee63d751d41f version: '3' # proxy services: nginx-proxy: image: jwilder/nginx-proxy container_name: nginx-proxy ports: - "80:80" - "443:443" volumes: - html:/usr/share/nginx/html - dhparam:/etc/nginx/dhparam - vhost:/etc/nginx/vhost.d - certs:/etc/nginx/certs:ro - /var/run/docker.sock:/tmp/docker.sock:ro - /srv/docker/nginx-proxy-with-encrypt/log:/var/log/nginx labels: - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy" restart: always letsencrypt: image: jrcs/letsencrypt-nginx-proxy-companion container_name: nginx-proxy-lets-encrypt depends_on: - "nginx-proxy" volumes: - certs:/etc/nginx/certs:rw - vhost:/etc/nginx/vhost.d - html:/usr/share/nginx/html - /var/run/docker.sock:/var/run/docker.sock:ro volumes: certs: html: vhost: dhparam: networks: default: external: name: common_link services: cantaloupe: image: islandora/cantaloupe:2.0.10 environment: CANTALOUPE_ENDPOINT_ADMIN_ENABLED: false CANTALOUPE_ENDPOINT_ADMIN_SECRET: my_admin_pass CANTALOUPE_SOURCE_STATIC: S3Source CANTALOUPE_S3SOURCE_ACCESS_KEY_ID: ${CANTALOUPE_S3SOURCE_ACCESS_KEY_ID} CANTALOUPE_S3SOURCE_SECRET_KEY: ${CANTALOUPE_S3SOURCE_SECRET_KEY} CANTALOUPE_S3SOURCE_REGION: ${CANTALOUPE_S3SOURCE_REGION} CANTALOUPE_S3SOURCE_BASICLOOKUPSTRATEGY_BUCKET_NAME: ${CANTALOUPE_S3SOURCE_BASICLOOKUPSTRATEGY_BUCKET_NAME} CANTALOUPE_S3SOURCE_LOOKUP_STRATEGY: BasicLookupStrategy # Or another strategy if needed VIRTUAL_HOST: <カスタムドメイン> LETSENCRYPT_HOST: <カスタムドメイン> LETSENCRYPT_EMAIL: <メールアドレス> restart: always networks: default: external: name: common_link まとめ IIIF画像サーバの小中規模の利用にあたっては、上記のような形が比較的容易な導入方法の一つに当たるかと思います。 ...

2024年1月27日 · 更新: 2024年1月27日 · 1 分 · Nakamura
Cantaloupe: Amazon S3に格納した画像を配信する

Cantaloupe: Amazon S3に格納した画像を配信する

概要 IIIFイメージサーバの一つであるCantaloupe Image Serverについて、Amazon S3に格納した画像を配信する方法の備忘録です。 なお、Amazon S3に格納した画像を配信する別の方法として、以下の記事で紹介した方法もありますので、参考になりましたら幸いです。（記事執筆時点からツールが更新されているようで、記事通りに進められないかもしれません。） 設定 以下に公式マニュアルが公開されています。 https://cantaloupe-project.github.io/manual/5.0/sources.html#S3Source 以下のファイルを編集します。 /cantaloupe-5.0.5/cantaloupe.properties まず、source.staticをS3Sourceに変更しました。 ########################################################################### # SOURCES ########################################################################### # Uses one source for all requests. Available values are `FilesystemSource`, # `HttpSource`, `JdbcSource`, `S3Source`, and `AzureStorageSource`. # source.static = FilesystemSource source.static = S3Source 次に、S3Source.access_key_id、S3Source.secret_key、S3Source.BasicLookupStrategy.bucket.nameを設定します。 #---------------------------------------- # S3Source #---------------------------------------- # !! Endpoint URI. Only needed for non-AWS endpoints. S3Source.endpoint = # !! AWS region. Only needed for AWS endpoints. S3Source.region = # !! Credentials for your AWS account. # See: http://aws.amazon.com/security-credentials # Note that this info can be obtained from elsewhere rather than setting # it here; see the user manual. S3Source.access_key_id = <アクセスキー> S3Source.secret_key = <シークレットキー> # How to look up objects. Allowed values are `BasicLookupStrategy` and # `ScriptLookupStrategy`. ScriptLookupStrategy uses a delegate method for # dynamic lookups; see the user manual. S3Source.lookup_strategy = BasicLookupStrategy # !! Name of the bucket containing images to be served. S3Source.BasicLookupStrategy.bucket.name = <バケット名> これでAmazon S3に格納した画像が参照されるようになりました。 ...

2023年11月16日 · 更新: 2023年11月16日 · 1 分 · Nakamura