こんにちは、後藤です。
今年度はAWS社よりAPN Ambassadorに選出いただきました。そして、その流れで「Japan APN Ambassadors Advent Calendar 2021」に参加させて頂いております。Ambassadorとは「大使」という意味で、社外への情報発信を評価されており、私も皆さんにとって有益な情報を発信したいところです。
何が良いかと考えた結果、私の居住地に関係するAWS情報を発信する事としました。
住んでいる場所は…………
写真で分かりましたでしょうか？
大阪のシンボル『太陽の塔』を後ろから撮った写真を掲載してみました。皆さん見慣れた前からの姿とは全く異なるのが面白いところです。そして、今からお話するのは今年新しく開設された『大阪リージョン』の軌跡になります。
という人の為に、大阪リージョンの歴史を少しだけ振り返りたいと思います。
なお、いつものお約束ごとですが、本投稿内容は、わたし個人の意見や経験談であり、所属する企業や団体、それこそ APN Ambassadors や AWS さん、JAWS-UG などを代表するものではございません。何卒、よろしくお願いいたします。
#■元々は世界唯一のローカルリージョン
まず日本に初めてAWSのリージョンが誕生したのは2011年3月ことのでした。
『クラウドが日本に上陸 (The Cloud Expands to Japan)』
AWSの新しい アジアパシフィック東京リージョンが利用可能になりました！日本でビジネスを行う企業様、また日本の顧客をもつグローバル企業の皆様は、本日より東京リージョンを使う事で、レイテンシーが低く、国内にデータ保管ができる環境でアプリケーションの提供や作業が可能となります。そして自社インフラの運用、管理といった煩雑な作業から解放されます。ほとんどの場合において日本のお客様は数ミリ秒という低いレイテンシーで新しい東京リージョンをご利用いただけます。
そこから7年間は東京オンリーの時代が続きました。
そんな中、2018年2月に新しいリージョンが誕生します。
『【 AWS 新リージョン】 AWS 大阪ローカルリージョンが本日より利用可能になりました』
日本で2番目、ローカルリージョンとしては AWS 初となる、 Asia Pacific (Osaka) Local Region（以下、AWS 大阪ローカルリージョン）がご利用いただけるようになりました。 2017 年 5 月 31 日 AWS Summit Tokyo 2017 の基調講演にて、 2018 年より利用できるお知らせをしました。AWS 東京リージョンをお使いのお客さまにおいては、規制対応のため補完的なインフラストラクチャを準備し、アベイラビリティゾーン間を地理的に離す必要のある特定のアプリケーションの運用が可能になる点、多くの反響をいただきました。
ついに関西にAWSリージョンが誕生した瞬間でした！
でも『ローカル』と付いていました。
単一のデータセンターに含まれるインフラストラクチャは分離されかつ対障害性のある設計で、既存の AWS リージョンを補完する新しいリージョン構成となりました。東京リージョンから 400 キロ離れた大阪ローカルリージョンは、東京リージョンだけでは難しい災害対策の提供を目指して、国内のさまざまな場所で必要とされるアプリケーションを持つお客様をサポートしてきました。
そう『大阪ローカルリージョン』はバックアップとDR（障害復旧）をメインとしたリージョンでした。その為、メインリージョンとして利用することはできず、機能面でも多くの制限がありました。大規模災害で東京リージョンが利用不可となった時に、最低限の復旧を想定した環境だった訳です。
ただし『ローカルリージョン』は『世界唯一』の存在。
『世界唯一』ってカッコよくない？
という気持ちも数パーセントありましたが、やはり完全体がいい………
#■やっぱりフルリージョンがいい！
そう思っていた2020年にニュースが飛び込んできました。
『AWS 大阪ローカルリージョンをフルリージョンへ拡張中』
大阪でのサービスに対するお客様からの大きなご要望にお応えし、大阪のローカルリージョンが 2021 年初頭までに 3 つのアベイラビリティーゾーンを持つ完全な AWS リージョンに拡大することになりました。 他のすべての AWS リージョンと同様、アベイラビリティーゾーンはそれぞれ独自の電源、冷却システム、物理的セキュリティにより分離されます。また、可用性に影響を与える単一のイベントのリスクを大幅に減らすため離れて配置されますが、高可用性アプリケーションの低レイテンシーは維持されます。
ついに『東京リージョン』に肩を並べる時がやってきたわけです。当時他のクラウドサービスでは東西フルリージョンを所持していたので、ここがAWSのウィークポイントと感じていました。それを一気に解消するフルリージョン化な訳です。
『ソニー銀行、勘定系を含む全てのシステムに AWS の利用可能範囲を拡大』
勘定系システムにおいて AWS を採用するには、自然災害や停電などのリスクを最小限に抑えるために、日本国内の複数のリージョンを必要とします。2018 年の大阪ローカルリージョン開設をふまえ、当社は銀行システムにおいて最も重要なシステムのひとつである財務会計システム（総勘定元帳）の AWS 移行を決定しました。
『大阪ローカルリージョン』がフルリージョンになることにより銀行系の重要システムの移行が決定するような場面もありました。クラウド活用が推進される中、『大阪ローカルリージョン』のフルリージョン昇格は必要不可欠だった訳です。
#■そしてフルリージョン開設！
ついに2021年3月に、待ちに待ったフルリージョンへの昇格が実現します。
『AWS アジアパシフィック (大阪) リージョンが3つのAZと多くのサービスと共に開設』
大阪ローカルリージョンを拡張して3つのアベイラビリティーゾーンを持つスタンダードな AWS リージョンとして大阪リージョンが開設されたことを発表できることを嬉しく思います。AWSならではの特徴として、それぞれのAZはリージョン内で切り離されており、停電やネットワークの切断、洪水やその他の自然災害に対応する設計です。
この瞬間、世界唯一の『ローカルリージョン』は消滅しました。
数パーセント残念な気持ちもありつつ、エンジニア的には国内に2つのリージョンができたことにより、多くの案件の要件を満たすようになり、提案の幅が広がったことに喜びを感じていました。
ちなみにAWS社が選択した大阪のシンボルは『大阪城』でした。『復興天守やん！歴史的価値無いやん！』ってよく言われますが、知らない間に『世界最古の現存する鉄骨鉄筋コンクリート造建築』になっていて、何気に価値が高かったりします（諸説あり）。世界最古の木造建築である『法隆寺』と同じノリで自慢できるところが何気に凄いです。
#■これで東京リージョンと肩を並べたの？？
肩を並べた！そう思った人もいたでしょう。
いや、肩を並べてないよ！
大阪リージョンには2021年3月時点ではまだまだ利用できないサービスが多々ありました。重要な機能も幾つサポートされていなかったため、開設当初はまだまだ用途が限定される状況でした。しかし、ここから怒涛のリリースラッシュが始まります。
今回は主に「Amazon Web Services ブログ」の記事をベースに、そのリリースラッシュを振り返ってみようと思います。なお、ブログ更新日を日付欄に記載しているため、実際のサービスリリース日とは若干誤差があることとご承知おきください。
3～7月くらいは本当に怒涛のリリースラッシュでした。
そして、11月頃にはそのリリースラッシュも落ち着いてきたのです。
#■そして現在（2021年12月）！サービス差異は？
そして2021年12月となりました。現在東京と大阪のリージョンで、どの程度のサービス数の差異があるのでしょうか？AWSのリージョンごとの利用可能サービスは「AWS リージョン別のサービス」で確認することができます。サービス数の比較結果は以下の通りです。
| 項目 | サービス数 |
|---|---|
| 東京リージョン | 180 |
| 大阪リージョン | 90 |
ジャスト半分でした！ |
まさに道半ばですね。
東京リージョンにあって大阪リージョンに無い90個のサービスはこちらです。
なかなか書き出すと壮観です。個人的には「AWS Budgets」、「AWS CloudShell」、「AWS Control Tower」、「AWS Single Sign-On」、「Amazon AppStream 2.0」、「Amazon CodeGuru」、「Amazon Inspector」、「Amazon Kinesis Data Analytics」、「Amazon Kinesis Video Streams」、「Amazon QuickSight」、「Amazon WorkSpaces」辺りは、早く大阪リージョンにリリースしてくれたら嬉しいところです。
#■それ以外の差異はないの？
まぁ、その90個のサービスさえ使わなければ差異はないんだろ…………
そういう声が聞こえてきそうです。
多くのサービスがリリースされましたが、そのサービス内の機能に関して、細かいところで東京リージョンと差異があるのが現実です。ここではAWSの主要な幾つかのサービスを確認しながら、その差異について説明したいと思います。
##EC2
料金的には互角です。ただ利用できるインスタンス数には大きな差があるのが解ります。
##EBS
料金的には互角です。ただし「プロビジョンド IOPS SSD (io2) 」は大阪リージョンにはリリースされておらず、東京リージョンでしか使えません。io1とio2の違いは以下の通りです。
io1 ボリュームは、0.2% 以下の年間故障率 (AFR) で 99.8～99.9% のボリューム耐久性を提供するように設計されています。これは、1 年間に実行中のボリューム 1,000 個あたり最大 2 つのボリュームの故障に相当します。io2 ボリュームは、0.001% 以下の AFR で 99.999% のボリューム耐久性を提供するように設計されています。これは、1 年間に実行中のボリューム 100,000 個あたり 1 つのボリュームの故障に相当します。
##S3
料金的には互角です。ただし「S3 Object Lambda」機能は東京リージョンにしかありません。
S3 Object Lambda を使用すると、S3 GET リクエストに独自のコードを追加して、データがアプリケーションに返されるときにそのデータを変更および処理できます。
##Lambda
東京リージョンのみが「Arm」アーキテクチャーを利用できます。
Armの方が費用対効果が高いため、東京リージョンの方が金額的なメリットがあります。
Arm/Graviton2 アーキテクチャを使用する関数の場合、時間料金は x86 の現在の料金よりも 20% 低くなります。同じ 20% の削減は、プロビジョニングされた同時実行を使用する関数の時間料金にも適用されます。
##RDS
インスタンスタイプの数が東京リージョンの方が多いのです。料金的には同額のDBサービスが多いですが、Oracleの様に明らかに大阪リージョンが高いサービスもあります。以下は「RDS for Oracle オンデマンド DB インスタンス (ライセンス込み)」の費用比較となります。
##その他
ちなみに、このサービス差異に関しては基本的に新サービスが東京リージョンで先にリリースされるという流れも影響しています。新しいサービスを早く利用したい場合は東京リージョンを選択する必要があります。
また、DirectConnectによる接続サービスなどでは「大阪リージョンへの接続はまだ対応していない」というサービスもあります。そういった周辺環境も大阪リージョン向けに整備が進んでいるところですので、注意が必要です。
#■じゃあ大阪リージョンはどんな時に使うの？
ここまでの説明で東京リージョンと大阪リージョンには差異があることがご理解いただけたかと思います。
確かにレイテンシー面でメリットはあるかと思いますが、使いたい機能が使えなければ意味がありません。
使いたい機能が使えるか？何を優先すべきか？
それをしっかり考えて、東京リージョンと使い分ける必要があります。
使いたい機能を検討する場合に大事な事は、
東京リージョンと同じサービスが利用できる訳ではない。
という点です。ここまで見てきた通り、サービスのリリース数には90個の差異があります。そして細かい機能についても差異がある訳です。その為、使いたい機能がある場合は、まずは大阪リージョンで問題なく動くかテストすることをお薦めします。AWSは実際の環境で動作確認することは容易ですので、自分のAWSアカウントで実際に確認するのが確実です。
現物を見て現実を知る。
それがとても大事だと思います。
もちろん国内に東京と大阪の2つのリージョンが存在する価値は計り知れません。
大阪リージョンの誕生は、たくさんの夢を与えてくれました！
今後も大阪リージョンが発展していくことを楽しみにしています。
以上が大阪リージョンに関するまとめ記事でした。
皆様にとって少しでも参考になれば幸いです。
…………これで締めようかと思いましたが、最初に載せた『太陽の塔』が後ろ姿だったのでムズムズしている人もいるかと思うので、最後はきちんと前面からの『太陽の塔』を載せておこうかと思います。こちらが表のお顔です。前面の顔が『現在』、背面の顔が『過去』、そして金色の顔が『未来』を表現しているとか。えっ、金色の奴顔なん！っと思った方、『太陽の塔』は色々と奥深いのです。
実は『太陽の塔』は最近では内部も公開しています。
中には『生命の樹』が存在しています。
どんな樹なのか気になる方。
それは是非、『現場に来て現物を見て』ください。
実際に自分の目で見て共感するのって大切だと思います。
GO TO OSAKA！！
それでは、最後までお付き合いいただき、ありがとうございました。