Azure コミュニティ

Global Azure Bootcamp 2017@Tokyo に参加した

4/22 品川の MS 本社で JAZUG が主催した、Global Azure Bootcamp 2017@Tokyo に参加しました。

■申し込みサイト
https://jazug.connpass.com/event/52917/

 

東京に引っ越ししてからの初のコミュニティイベントの参加です。
で、JAZUG の SGT 開催に参加するのも初めて。
ざっくり感想を言っちゃうと、楽しい以外の何物でもなかったです。

入館チケットの配布をしたり、サブウェイの受け取りに一緒に行ったりと、イベントの裏方業務はやっぱり好きだなー。
もちろん勉強会自体もとても興味深いセッションばかりでしたし、参加者の数も申し込みサイトの人数でトータルで187人ですので、スケールも大きくて、Azure に興味を持つ方が増えるといいなーって思ってみたり。

札幌のイベントと比べると、申込者がすごく多いけど、キャンセルする人もすごく多くて、それもびっくりでした。
ただ、実際に参加された人数は150人を超えていると思うので、当日に連絡なし欠席をした方はそんなに2割強ってところなのかな。
札幌だと、連絡なし欠席は1・2名ですが、これは規模の違いなんでしょうね。

多くの方が参加されたイベントの運営をお手伝いできたのは、やっぱり楽しかったな。

セッションの感想

セッションは、7 セッション + LT と結構盛沢山な感じです。

  • Azureって何よ2017年の最新情報をゆるまとめ
  • Azure 2017年3月障害Deep Dive
  • bitFlyerを支える仕組み - Azure障害の中1時間未満でサービス復旧を実現-
  • サポートエンジニアが紹介する、Azure Portal/CLI 使いこなし
  • Azure ML系 「practice over theory」
  • DocumentDB DeepDive
  • オルターブースさんのAzure事例(松村さん、森田さん.NET CoreとACS、Web Apps)
  • LT

各セッションの資料は、申込サイトに順次アップロードされていて、ほとんどそろっていたと思います。

また、当日の雰囲気を知りたい方は、Twitter まとめを見て頂くといいと思います。
https://togetter.com/li/1103228

 

以下、自分が印象に残ったこと

Azure 2017年3月障害Deep Dive

  • 3/8のストレージ障害の Root Cause Analysis の内容を読み解くセッション
  • Stream Manager って何?
    → Azure ストレージシステムで Stream Manager が何をしているか理解する
  • ストレージ内のオブジェクトの URL が URI となるように設計されている
  • ストレージスタンプ
    ラック10~20本のサーバの塊
    フロントエンドレイヤー,パーティションレイヤー,ストリームレイヤーの3つの役割
  • ロケーションサービス
    ストレージスタンプを管理
    アカウントと名前空間の対応を管理
  • フロントエンドレイヤ
    ユーザーからの要求を受け付ける役目
  • パーティションレイヤ
    サービスに対応したデータの管理(Blob,Table,Queue,File)
    トランザクションと一貫性
    パーティションによるスケーラビリティ
  • ストリームレイヤ
    データを永続化する役割(DFS)
    3つのレプリカ
    パーティションレイヤにだけインターフェースを提供
    既存のデータを変更するインタフェースは持たない
    ストリームの単位でデータを管理
  • 2つのレプリケーション
    スタンプ間レプリケーション
    ・ストリームレイア間で実行
    ・LRS を実現
    ・ハードウェア障害などに対するデータの耐久性を提供。
    ・レプリケーションは同期的
    スタンプ内レプリケーション
    ・パーティションレイア間で実行
    ・ZRS、GRS、RA-GRS を実現
    ・被災障害などに対するデータの冗長性を提供。
    ・レプリケーションは非同期的
  • Paxos プロトコル
  • ソロモンコード
  • ストリームの構造
    ストリーム
    ・エクステントへのポインタ
    エクステント
    ・ブロックの塊
    ブロック
    ・データを読み書きする最小単位
  • ストリームマネージャー
    ストリームとエクステントを管理
    エクステントノードでエクステントとブロックを管理
    エクステントノードが3つのレプリカの実体
  • ストリームマネージャーの役割
  • ストリームマネージャーはデータ破損を検出したら、復旧処理を行う。
    新しエクステントノードを作って、プライマリからレプリケーションする
  • 今回の事象は、ストリームマネージャが予期せぬ状態となってその間ストレージサービスへのアクセスができなくなった。
    ストリームマネージャーは自己回復の機能があったけど、バグがあって自己回復できなかった。

bitFlyerを支える仕組み - Azure障害の中1時間未満でサービス復旧を実現-

  • 9/15 DNS 障害機器のバグ
    Worker Roll から DB が引けなくなった
    直接 IP で RDP できるといいかも
  • 3/8 東日本ストレージ障害
    Radis Cache を西日本に展開しなおして、接続文字列を変えてデプロイ
    緊急時の予行演習を事前にやる必要性
    サービスのステータス開示をする機能の必要性
  • 3/28 西日本ストレージ障害 メンテの失敗
    Radis Cacheが死んだので、西日本から東日本へ移動
    西日本と東日本のペアリージョンは信頼できるかも
  • 3/31 東日本ストレージ障害 空調設備(RPUS)の電源故障(冗長化構成がちゃんと機能しなかった)
    SQL Database が不安定になって、Cloud Services の VM に接続できなくなった。
    その後、SQL Database も応答なしになって、サービスダウン
  • 東が全滅っぽい感じだったから西日本への引っ越しを判断
  • DBはGeoレプリケートの構成だったが、西日本は小さいサイズだったのでスケールアップが必要だった
    →手順としては、スケールアップ後レプリカがいいらしい
  • ジオ障害にむけたストレージの対策
    本当に重要なところはジオ冗長をやった方がいいかも
    →実際にジオ冗長で切り替わったことはまだないらしい(12時間以上というしばりが。。)
    クラウドサービス用のアセットは別ストレージに入れておいた方がいいかも
    CDNをつかってエッジサーバに退避させるというのも一つの方法かも
  • ジオ障害にむけたCloud Serviceの対策
    別のジオにデプロイ
    →一斉にデプロイするといつもよりも時間かかるかも
    DNSの設定変更をお忘れなく
  • DNSの障害に向けた対策
    DNSが死んでも、キャッシュで動けてたりする場合があるので注意が必要
    DNSが死ぬと色々うごけなくなるので、冗長化の構成を組んでおくといいかも
  • Readis Cacheに向けた対策
    重要なデータ入れない(そもそもキャッシュだし)
    ウォームアップ時間が結構かかる(30分とか)
    →この時間が許容できない場合は、事前に作って動かしておいた方がいいかも
  • SQL Databaseに向けた対策
    アプリ側で接続文字列を簡単に変えられるようにしておいた方がいいかも
    バックアップはとろう
    Geoレプリケーション使おう
    1つのDBから複数同期はやめたほうがいい
  • ペアリージョンはそれなりに効果はありそう

まとめ

全体を通して、機能の紹介的なセッションはなくて、すべて深堀する内容だったので楽しかったです。
なんとなく去年あたりから、Azure を使うってことは世の中的にある程度受け入れられてきて、その中でどうやって使い倒すかってところに話題が移ってきていると思います。
そんな中で、障害系の話にはどうしても注目があつまるのかなって思っています。

運用とかセキュリティとか、その辺もどんどん盛り上がってくるんだろうなって思いました。

次回は、JAZUG女子部が5/17に予定、JAZUGは6月に勉強会を予定しているみたいです。

-Azure, コミュニティ
-, ,