先日、仕事で、さくらのVPSを使ってサーバを構築しようとしていたら…。東京リージョンのVPSがいずれのサイズでも「在庫なし」になっていた。本当は東京リージョンで構築しようと思っていたんだけど。まぁ、大阪でもいいんだけどさ…。
そういえば、大阪リージョンでのVPSの在庫が復活したときに、東京、大阪、石狩の3拠点でDRできますってのをウリにしてたじゃーんって無駄絡みしたくなるのは人情ってヤツだろうか。東京リージョンのVPSではハードウェアの老朽化対応メンテナンスを実施していて、いろいろと整理してそうで、それと関係あるんだろうか。
どうやら、F5 Networks,Inc.がnginxを買収したらしく。
そういえば、(オープンソースなソフトウェアルータのVyattaを開発してた)Vyatta社を買収したbrocadeがVyattaのオープンソース版の公開を中止して、コミュニティーがフォークしたVyosが生まれたことを思い出したりするけれど…(いつの間にか、brocadeがAT&TにVyattaを売却してたらしく、今ではAT&Tの子会社になってるそうだ)
はてさて。
どうやら、そういうことらしい。
Amazon RDS for MySQL と Amazon RDS for MariaDB が T3 インスタンスタイプをサポート開始
Amazon Relational Database Service (RDS) for MySQL および Amazon RDS for MariaDB を使用する際に、T3 インスタンスタイプを起動できるようになりました。Amazon EC2 T3 インスタンスは次世代の汎用バーストインスタンスタイプで、ベースラインレベルの CPU パフォーマンスとともに、必要なときにいつでも無期限で CPU 使用率をバーストできる機能を備えています。
EC2に新しいインスタンスタイプがリリースされて、近々、RDSでも新しいインスタンスタイプが使えるようになるんだろうなぁ…と思いつつ、目前に迫ったリザーブドインスタンスの有効期限を睨みながら「ちっ」とか思いながら旧世代のインスタンスでリザーブドインスタンスを買っちゃった翌週くらいに、新しいインスタンスタイプがRDSで使えるようになって遠い目になるのは何回目だろうか…。いやはや。
とはいえ…。
>AWSの中の人
Auroraでt3インスタンスを使えるようにしてくれてありがとう。
このブログを動かしているサーバを、AWSのOregonリージョンのA1.mediumインスタンスで建ててみた。A1インスタンスというと、AWSの子会社が開発した汎用ワークロード向けARMプロセッサ(AWS Graviton Processors)で動いているサーバで、一瞬、大丈夫かなぁと思ったものの、実際にPHPやRedisなどをビルドしてみると普通にビルドできたし、今のところ、普通に動いているように見える。
まぁ、実際のところ、A1.mediumインスタンスであれば、月額1,000円ちょっとで動かせてサーバのメモリが2GB確保されているのはかなりお得なんじゃないだろうか。もし、仮に多少、CPUがショボかったとしても、私のブログ群のように対してトラフィックがないサイトにとってはCPUリソースが枯渇するなんてことはほぼない訳だし、うっかりメモリが枯渇しちゃってOOM Killerが猛威を振るうことの方が恐ろしいような気もする。むしろ、MySQLやRedisにたっぷりメモリを使わせる方が速くなったりしないだろうか…ま、時と場合によるか。
まぁ、ただ、aarch64アーキテクチャ向けにビルドしてある、新しめ(=10.x系)のMySQL/MariaDBのがAmazon Linux2のyumレポジトリになくて、仕方なくMariaDB5.5で動かしているけれども、WordPressなら大した差にはならないんじゃないかと信じている(そういえば、FULLTEXTインデックスに対応してなくて前のサーバからmysqldumpで引っ張り出したSQLがコケた時はちょっと遠い目になったくらいか)
今日はソフトバンクのLTE網が割と長い時間にわたって障害を起こしてたなぁ…って印象だったけど、どうやら、ソフトバンクの障害の原因は、LTEネットワークを構成するノード群の中のMME(Mobility Management Entity)と呼ばれる装置だったようで、2016年2月に出されたEricssonのプレスリリースによれば、ソフトバンクはEricssonが提供するvMMEを導入していて、このvMMEが障害を起こしたことが原因だったらしく。
そして、このMMEと呼ばれるノードは、DoCoMoのTechnology Reportsによると
MMEは，位置登録，ページング、ハンドオーバなどの移動制御、およびベアラ確立／削除を行う
という役割を果たしているとのことなので、これが止まってしまうとネットワークが全く機能しなくなるくらいに重要なノードであろうことは想像に難くない。
で、このvMMEは仮想環境で動いている(vMMEのVは「Virtual」)ようで、ソフトバンクのLTE網に障害をもたらしたものと同じソフトウェアがイギリスのO2ってキャリアでも使われていて、イギリスのO2でも大規模な障害に繋がってしまったようで、なんともこれは…と。
一応、イギリスのfinancial timesが記事にしてた。
Ericsson software problem leads to global smartphone outage
追記:
ITmediaも記事を公開してました。
ソフトバンク通信障害はエリクソン製設備が原因か Financial Times報道
追記 その2:
あと、Reutersの記事によるとEricssonの広報も、顧客(=通信キャリア)と問題解決に取り組んでいることを認めたみたいですな。
“We are aware of the issue and are working together with our customers to solve it as soon as possible,” an Ericsson spokesman said.
追記 その3:
ケータイWatchの記事によれば、2016年当時、ドコモはEricsson、Cisco、NECのマルチベンダーで導入した一方、ソフトバンクはEricssonのシングルベンダーで導入していたそうだ(ただし、今回の障害の原因となったMMEに限定した話ではなさそう)
マルチベンダーでの導入は今回のような事象にはメリットがあるかもしれないけれど、ベンダーの違いをうまく吸収しながら安定運用を目指すとなると、運用の複雑さや、機器にかかるコストなんかはデメリットになりそうなので、マルチベンダーで導入するのが正解といったシンプルな話ではなさそうな気はする。
追記 その4:
ソフトバンクがお詫び文のPDFを公開。この文書によると、原因について
2018年12月6日（木）午後1時39分ごろ、全国のお客さまをカバーする、東京センターおよび大阪センターに配置してある、エリクソン社製パケット交換機全台数で、同社ソフトウエアに異常が発生しました。なお、同ソフトウエアは９カ月前から運用しており、同ソフトウエアによる異常は、エリクソン社製の通信設備を使用する海外（11カ国）の通信事業者においても、ほぼ同じ時刻に同様に発生していると、エリクソン社から報告を受けています。ソフトウエアを旧バージョンに戻すことで、復旧を行いました。
との記載があった。9ヶ月前から使っていたソフトが、時限爆弾のように突然障害を起こすなんてなかなかの恐怖だなぁ…いやはや。
追記 その5:
Ericssonがプレスリリースを出していた。それによると、障害が起きた顧客(SoftBankやO2など)が使っていたソフトウェアのバージョンには、有効期限切れの証明書が使われていたことが障害の原因となったとのこと。
An initial root cause analysis indicates that the main issue was an expired certificate in the software versions installed with these customers.
確か、ソフトバンクのプレスリリースではアプリケーションを切り戻して復旧させたと書いてあったんだけど、9ヶ月前に運用を始めたバージョンには有効期限切れの証明書が使われていて、切り戻した(=現在、利用している)、さらに古いバージョンには有効な証明書が入っていたということはリリース時の手違いか何かで古い証明書を入れちゃったってことだろうか。
今回の大規模障害のせいで、ソフトバンクは上場直前のこのタイミングで総務省に怒られることは間違いない(そういえば、指針に沿わない不適正な端末購入補助の件で既に総務省に怒られているのに、それに加えて…ってのはキツい)だけに、ネットワークベンダー起因のトラブルで自社のネットワークが大規模にダウンするのはどうなのよってことになったりしないもんだろうかって気もしないでもないけれど、はてさて、どうなることやら。
参考リンク：
© 2019 ただのにっき。
Theme by Anders Noren — Up ↑