2019年8月26日月曜日

AWS東京リージョンで大規模障害が発生

先週の金曜日午後、AWS東京リージョンで大規模な障害が発生しました。復旧までにほぼ半日かかったようです。私個人で利用していたEC2は特に問題はなかったのでAZ(アベイラビリティゾーン)が違っていたようです。

日経xTechでは障害により影響があったサービスの例が掲載されていました。

AWS大障害、ユニクロ・楽天・PayPayなど30社以上に影響

障害発生時、Twitterではゲーム系のサービスがダウンしているのは見かけていましたが、こちらの一覧を見るとゲームだけではなくECやネットサービス系の大手も影響があったようです。

AWSから障害に関する公式発表が出ています。

東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要

これによると
今回の事象はデータセンターで使用されるいくつかの冷却システムの制御と最適化に使用されるデータセンター制御システムの障害によって引き起こされました。制御システムは、高可用性を実現するために複数のホストで実行されます。
<中略>
サードパーティ製の制御システムにおけるロジックのバグにより、この情報交換が制御システムとデータセンターのデバイス間で過度に発生し、最終的には制御システムが応答しなくなりました。AWS のデータセンターは、データセンターの制御システムに障害が発生した場合、制御システムの機能が回復するまで冷却システムが最大冷却モードになるよう設計されています。これはデータセンターのほとんどで正常に機能していましたが、データセンターのごく一部で冷却システムがこの安全な冷却構成に正しく移行できず停止しました。
<中略>
運用チームは、影響のあるデータセンターのエリアで冷却システムを「パージ」モードにしようとしましたが、これも失敗しました。この時点で、データセンターの影響を受けるエリアの温度が上昇し始め、サーバーの温度が許容限度を超え、サーバーの電源が停止し始めました。

根本的には制御システムの不具合のようですが、サーバーが停止したのは温度上昇という物理的なものだったとはちょっと以外でした。

今回の障害は東京リージョンにある4つのAZのうちの1つで発生したという事ですが、 AWSの報告の最後にはこう記してあります。
この度の事象発生時、異なるアベイラビリティゾーンの EC2 インスタンスや EBS ボリュームへの影響はございませんでした。複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。アプリケーションで最大の可用性を必要とされるお客様には、この複数アベイラビリティゾーンのアーキテクチャに則ってアプリケーションを稼働させることを引き続き推奨します
もともとAWSは稼働率を上げるためにはAZを跨いだ冗長構成にする事を推奨していました。お手軽に使えるクラウドサービスですが、物理的にはデータセンターであることには変わりありません。障害は発生する前提でその対応策としてのシステム構成を設計する事がインテグレーターとしては求められます。








2019年8月22日木曜日

2019年8月19日月曜日

CIツールとの連携③ - MSBuildによるチーム開発その1

さて、次はいよいよチーム開発機能をMSBuildで利用します。

チーム開発機能とはGeneXus Serverとの連携を意味し、GeneXus IDE上では「Serverからナレッジベースを作成」「ナレッジベースをServerへ送信」「アップデート」「コミット」等の操作になります。

まずはプロジェクトファイルです。




チーム開発機能を使用するためにはtargetsファイル(GeneXus.Server.Tasks.targets)のインポートを追加します。

今回は「Serverからナレッジベースを作成」を試してみます。PropertyGroupで必要な操作に必要なプロパティを定義しています。