はじめに
こんばんは。クラウド事業部 安藤です。
OCIの資格取得にあたり、Oracle MyLearnを使用したのですが、解説動画や資料でよく例に出てきたリージョン名「NRT」や「KIX」に、旅行好きな私はビビっときてしまいました。TYOやOSAではなく、その都市の主要な空港コードになっているのです!
そんな今回はOCI初学者として、ユニークだと感じたOCIのリージョン・キーについて投稿したいと思います。
リージョン・キーとリージョン識別子
OCIの公式ドキュメントを確認したところ、「NRT」「KIX」といったリージョン名は「リージョン・キー」、
「ap-tokyo-1」「ap-osaka-1」といったリージョン名は「リージョン識別子」としてそれぞれ定義されていることがわかりました。
リージョン識別子の方はAWSで用いるリージョン名と似た形式になっていますね。
OCIのリージョン一覧表
表より一部抜粋
| リージョン名 | リージョン識別子 | リージョンの場所 | リージョン・キー | レルム・キー | 可用性ドメイン |
|---|---|---|---|---|---|
| 日本中央部(大阪) | ap-osaka-1 | 大阪(日本) | KIX | OC1 | 1 |
| 日本東部(東京) | ap-tokyo-1 | 東京(日本) | NRT | OC1 | 1 |
AWS、Azureのリージョン名と比較してみる
AWSのリージョン一覧表
表より一部抜粋
| リージョン名 | リージョン | エンドポイント | プロトコル |
|---|---|---|---|
| アジアパシフィック(大阪) | ap-northeast-3 | rds.ap-northeast-3.amazonaws.com rds.ap-northeast-3.api.aws |
HTTPS HTTPS |
| アジアパシフィック(東京) | ap-northeast-1 | rds.ap-northeast-1.amazonaws.com rds.ap-northeast-1.api.aws |
HTTPS HTTPS |
Azureのリージョン一覧表
表より一部抜粋
| リージョン | 可用性ゾーンのサポート | ペアのリージョン | 物理的な場所 | 地理 | プログラム名 |
|---|---|---|---|---|---|
| 東日本 | ✓ | 西日本 | 東京、埼玉 | 日本 | japaneast |
| 西日本 | ✓ | 東日本 | 大阪 | 日本 | japanwest |
AWSでは東日本リージョンは「ap-northeast-1」、Azureでは「japaneast」と、それぞれ単一のリージョン名があることがわかりました。 OCIのように2種類の名称が公式で定義されているというのは珍しそうです。
「NRT」と「ap-tokyo-1」はどう使い分けるのか
ではOCIではこの二種類のリージョン名はそれぞれどのような場面で用いられるのでしょうか?
リージョン識別子
まず、リージョン識別子の方は、コマンド実行時の環境変数やAPIエンドポイントなど、システムがリソースの地域を特定するために必要な定義として多く使用されているようでした。
例:OCI CLI/SDK構成ファイル docs.oracle.com
ここではOCI CLI/SDKで必要な構成ファイルに書く基本的なエントリの中にデフォルトリージョンの指定があることがわかり、例としてリージョン識別子「us-ashburn-1」が指定されています。
[DEFAULT] user=ocid1.user.oc1..<unique_ID> fingerprint=<your_fingerprint> key_file=~/.oci/oci_api_key.pem tenancy=ocid1.tenancy.oc1..<unique_ID> region=us-ashburn-1
OCI CLIコマンドを実行する際に、構成ファイルに定義したのとは異なるリージョンを指定したい場合は、
--regionオプションを付けて、リージョン識別子で指定をします。
#ちなみに環境変数の優先度としては以下のとおりです。
- コマンド・オプションで指定された値。
- 環境変数に指定された値。
- OCI構成ファイルで指定された値。
また、OCIサービスへのAPIリクエストは、接続先のURL(エンドポイント)にリージョン識別子を含んだ形式であることもわかります。
例:オブジェクトストレージAPIのエンドポイント
https://objectstorage.ap-tokyo-1.oraclecloud.com https://objectstorage.ap-osaka-1.oraclecloud.com
リージョン・キー
一方リージョン・キーの方はどうでしょうか?
調べたところ、IAMポリシーの条件指定の際に使用されているのを見つけました。
例:IAMポリシーの条件
Allow group 'DomainA'/'NRT-Admins' to manage all-resources in tenancy where request.region = 'NRT'
IAMポリシーの設定時に、リクエストが発行されるリージョンで制限をかけるような条件を追加する際、request.regionとしてリージョン・キーで指定することができます。
以下のドキュメントで変数が示されています。
| 名前 | タイプ | 説明 |
|---|---|---|
| request.region | 文字列 | リクエストが発行されるリージョンの3文字のキー。指定できる値は次のとおりです。 ノート: 割当てポリシーの場合、次の3文字のキー値のかわりにリージョン名を指定する必要があります。詳細は、サンプル割当て制限も参照してください。 AMS - オランダ北西部(アムステルダム)に使用 ARN - スウェーデン中央部(ストックホルム)に使用 AUH - アラブ首長国連邦中央部(アブダビ)に使用 BEG - セルビア中部(Jovanovac)に使用 BOG - コロンビア中央部(ボゴタ)に使用 BOM - インド西部(Mumbai)に使用 CDG - フランス中央部(パリ)に使用 CWL - 英国西部(ニューポート)に使用 DXB - アラブ首長国連邦東部(ドバイ)に使用 FRA - ドイツ中央部(フランクフルト)に使用 GRU - ブラジル東部(サンパウロ)に使用 HSG - インドネシア北部(バタム)に使用 HYD - インド南部(ハイデラバード)に使用 IAD - 米国東部(アッシュバーン)に使用 ICN - 大韓民国中部(ソウル)に使用 JED - サウジアラビア西部(ジッダ)に使用 JNB - 南アフリカ中央部(ヨハネスブルク)に使用 KIX - 日本中央部(大阪)に使用 LHR - 英国南部(ロンドン)に使用 LIN - イタリア北西部(ミラノ)に使用 MAD - スペイン中部(マドリード)に使用 MEL - オーストラリア南東部(メルボルン)に使用 MRS - フランス南部(マルセイユ)に使用 MTY - メキシコ北東部(モンテレー)に使用 MTZ - イスラエル中央部(エルサレム)に使用 NRT - 日本東部(東京)に使用 ORD - 米国中西部(シカゴ)に使用 ORF - スペイン中央部(マドリード3)に使用 PHX - 米国西部(フェニックス)に使用 QRO - メキシコ中央部(ケレタロ)に使用 RUH - サウジアラビア中央部(リヤド)に使用 SCL - チリ中央部(サンチアゴ)に使用 SIN - シンガポール(シンガポール)に使用 SJC - 米国西部(サンノゼ)に使用 SYD - オーストラリア東部(シドニー)に使用 VAP - チリ西部(バルパライソ)に使用 VCP - ブラジル南東部(ヴィニェード)に使用 XSP - シンガポール西部(シンガポール)に使用 YNY - 韓国北部(春川)に使用 YUL - カナダ南東部(モントリオール)に使用 YYZ - カナダ南東部(トロント)に使用 ZRH - スイス北部(チューリッヒ)に使用 |
#ちなみにOCI CLIで以下のコマンドを実行すると、リージョン識別子と対応するリージョン・キーをリストアップすることができます。
oci iam region list --output table
出力例
+-----+----------------+ | key | name | +-----+----------------+ | FRA | eu-frankfurt-1 | | IAD | us-ashburn-1 | | ICN | ap-seoul-1 | | PHX | us-phoenix-1 | | NRT | ap-tokyo-1 | | LHR | uk-london-1 | | YYZ | ca-toronto-1 | +-----+----------------+
他にも調べてみましたが、リージョン識別子と比べると、必須のパラメーターとして指定するような場面というのは少なそうでした。
#OCIのコンソール画面に表示があったりするのかな?と思いましたが、リージョンの表記はJapan East (Tokyo)と、普通のリージョン名でした。
oracle-japan.github.io
感想
とはいえ、リージョン・キーは短い名称でリージョンの所在地を表現でき、説明の際にも読み上げやすく、直感的に判別しやすくて便利だと感じました。
設計図に入れたり検証する際などのリソース名につけたりと、人間にとっての運用上の利便性という観点でも有用だと思います。
さいごに
今回はOCIのユニークなリージョン・キーとリージョン識別子という切り口で調べてみましたが、比較する中で他のパブリッククラウドとの設計思想の違いが見えて来たり、そもそもOCIのIAMポリシーってどういう風に組み立てるんだっけなど、脇道での発見や理解の深まりがありました。
とりあえず飛行機乗ってきます。