Sorry Page実装時の背景
LBで特定の条件を満たさないIPからの接続をはじいた先のページとして、Sorry Pageの実装が必要になりました。
ブラウザで調べてみると、Sorry PageをOCIで実装する方法としてこのような方法があるとわかりました。
(1) Sorry ServerをComputeで用意
(2) Functionを利用した実装
(3) LB機能の活用
(4) API Gatewayを使ったwebサイトホスティング
それぞれの月額料金を比較
あまりお金をかけずに実装したいので、それぞれで今の構成に対してSorry Pageのために新たに課金が発生する項目をわかる範囲で洗い出しました。
2025年8月時点の金額です。
| 実装方法 | 追加月額費用 | 課金対象サービス |
|---|---|---|
| (1) Sorry Server | ¥5,963 | Compute (最小構成: 1 OCPU / 8GB) |
| (2) Function | ¥0 | WAF, OCI Function (無償枠内利用想定) |
| (3) LB機能活用 | ¥0 | - |
| (4) webサイトホスティング | ¥465 | API Gateway (100万リクエスト以内想定) |
最小構成とはいえ、新しくインスタンスを立てるComputeは最も高額になってしまいました。
他のサービスはOCIの無償枠の範囲で実装できれば無料だったり、かなり安く使えることもわかりました。
それぞれの構築方法を確認
(3)以外の実装方法については、すでにQiitaに記事がございましたので、そこから実装方法を確認しました。
（先人の方々の知恵！！本当に勉強になりました！！）
(1) Sorry ServerをComputeで用意
(2) Functionを利用した実装
(3) LB機能の活用
上記(1)記事内で"LBリダイレクト機能"として紹介されていた方法です。
こちらのリンクを確認すると、リリース日が2020年11月19日！
かなり前のリリースであるため、実際にできるのかを試してみたいと思います。
(4) API Gatewayを使ったwebサイトホスティング
先にこっちの記事しか見つけていなかったので、これを見ながら試してみました。
後々調べると、Qiitaにすでに同様の記事が！気づいておくべきでした・・
こちらの記事と類似した内容にはなりますが、今回試した方法も備忘としてこちらに残させていただきます。
ここから、(3)(4)について自分の環境で試した時の手順を記載します。
(3) LB機能の活用
こちらの構成の①→⑥→⑦→⑧の経路で省略して実装できないかなーと考えていました。
クラウド・ネイティブ・サービスを使用したロード・バランサのカスタム・エラー・ページの実装より引用
LBの設定
こちらのtutorialを参照して基本的な設定をしました。
表示させたいhtmlファイルをオブジェクトストレージに格納
サンプルとなるhtmlファイルを作成し、このファイルをオブジェクトストレージにアップロードします。
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>テストページ</title>
</head>
<body>
<h1>Hello from Object Storage</h1>
<p>これはLBのリダイレクトによって表示されたHTMLです。</p>
</body>
</html>
そのままアップロードする
"オブジェクトのアップロード"からアップロードします。
"オブジェクトのアップロード"からアップロードしたファイルは、object-storage_direct.htmlとします。
（後で同じファイルを別の方法でアップロードするため。）
このような形式でアップロードできました。
Cloud Shellを経由してアップロードする
先のネタバレになっちゃうのですが、上記方法でアップロードすると思うな動作にならなかったので、Cloud Shellを経由してアップロードしました。
object-storage_cloud-shell.htmlという名前でファイルをアップロードします。
matorii@cloudshell:~ (***)$ ls -l
total 40
-rw-r--r--. 1 matorii oci 234 Aug 5 02:40 ***.html
drwxr-xr-x. 3 matorii oci 19 Apr 18 2024 network
-rw-r--r--. 1 matorii oci 252 Aug 15 01:24 object-storage_cloud-shell.html ★
この★が付いているhtmlファイルをオブジェクトストレージに格納します。
格納する際に使用するコマンドはこちらです。
oci os object put \
--bucket-name *** \
--name "object-storage_cloud-shell.html" \
--file "index.html" \
--content-type "text/html" \
--force
実行するとこんな感じになりました。
matorii@cloudshell:~ (***)$ oci os object put \
> --bucket-name *** \
> --name "object-storage_cloud-shell.htm" \
> --file "index.html" \
> --content-type "text/html" \
> --force
Uploading object [####################################] 100%
{
"etag": "7a***",
"last-modified": "Fri, 15 Aug 2025 01:27:37 GMT",
"opc-content-md5": "D+***=="
}
matorii@cloudshell:~ (***)$
オブジェクトストレージの一覧からオブジェクト詳細を確認すると、確かにアップロードできています！
コンテンツタイプ
今回2種類の方法でアップロードしたのは、オブジェクトのコンテンツタイプを変更するためです。
| アップロード方法 | コンテンツタイプ |
|---|---|
| そのままアップロード | application/octet-stream |
| Cloud Shellを経由してアップロード | text/html |
コンソール上のボタンからアップロードすると、コンテンツタイプが変更できません。
そのままアップロードすると、コンテンツタイプがapplication/octet-streamになってしまい、どのようなファイルなのかを指定することができません。
しかし、Cloud Shellからアップロードすると、アップロードするコマンド内でコンテンツタイプを記述することができます。
そのため、このオブジェクトはhtml形式だと指定することができます。
ルール設定
ポリシーの作成
LBのメニューにポリシーを設定できる部分があります。
こちらのルールセットを作成します。
URLリダイレクト・ルールを設定します。
今回は/errorと一致した場合に、リダイレクトパスで指定したURLへリダイレクトするようにしました。
リダイレクトパスにはオブジェクトストレージのURLを記載したので、/errorがある場合にオブジェクトストレージのファイルを見に行くようなイメージです。
オブジェクトストレージに格納したオブジェクトのURLはこのようになっていると思います。
https://<テナント>.objectstorage.<リージョン>.com/n/<テナント>/b/<バケット>/o/object-storage_direct.html (オブジェクト)
前半部分をリダイレクト・ホストに記載し、
https://<テナント>.objectstorage.<リージョン>.com
後半部分をリダイレクト・パスに記載します。
/n/<テナント>/b/<バケット>/o/object-storage_direct.html (オブジェクト)
このように設定できました。
リスナーにルールを設定
先ほど作成したポリシーをリスナーにルールとして紐づけます。
すでにあるリスナーの編集ボタンを選択します
ルールセットに、先ほど作成したポリシーを追加します。
動作確認
直接アップロードしたファイルを指定
まず、コンテンツタイプがapplication/octet-streamになっているファイルをリダイレクト・パスに指定したときの挙動を確認します。
<LB パブリックIP>/errorに接続します。
オブジェクトストレージにあるファイルをダウンロードしてしまいました。
このまま実運用で使用すると、こちらがはじきたいアクセス方法でアクセスしたきたユーザーがサイトにアクセスしたら、急にファイルがダウンロードされるイメージです。
これは好ましい挙動とは言い難いです。
Cloud Shellからアップロードしたファイルを指定
そこで先ほど用意したコンテンツタイプがtext/htmlになっているファイルをリダイレクト・パスに指定してみます。
その状態で<LB パブリックIP>/errorに接続します。
おーーーー！！ちゃんとリダイレクトして作成したページが表示できました！！
マスキングしていますが、ページ上部に表示されるURLはポリシーで設定した
リダイレクト・ホスト + リダイレクト・パスになっています。
(3) LB機能の活用のまとめ
オブジェクトストレージに格納するファイルのコンテンツタイプを正しく指定すれば、LBのリダイレクト機能を利用して、Sorry Pageを実装できることがわかりました。
(4) webサイトホスティング
API Gatewayを使用してwebサイトホスティングを行いました。
自分の整理用に作成したので雑ですが、このような環境で検証しました。
API Gatewayの作成
基本的にはデフォルト設定のまま作成します。
ルーティングの部分だけ、以下のように設定しました。
URLの部分にオブジェクトストレージに格納しているオブジェクトURLを指定しています。
先ほどの動作確認の結果を踏まえて、今回はコンテンツタイプがtext/htmlになっているファイルのみ検証します。
ルール設定
(3)で設定した方法と同様に今回もリスナーにルールを設定します。
大事なところがマスキングされているのですが、作成したAPI Gatewayのホスト名を
リダイレクト・ホストに記載します。
動作確認
今回も<LB パブリックIP>/errorに接続します。
今回もAPI Gatewayを経由して作成したページが表示できました！
ページ上部に表示されるURLはAPI Gatewayのホスト名になっています。
(4) webサイトホスティングのまとめ
API Gatewayを使うことでもリダイレクトして想定のSorry pageを表示させることができました。
まとめ
今回(3)(4)の方法でLBのリダイレクト機能を使用してSorry Pageを表示させることができました。
リダイレクト機能を使用するので、環境によっては不適切な場合もあるかもしれませんが、安く簡単に設定できるので、選択肢の1つとして考えてみても良いかと思います。
今回のポイント
・オブジェクトストレージに格納するオブジェクトのコンテンツタイプ
・LBのリスナーへのルール設定