Azure クラウドデザインパターン de:code 成本さん

色違いヌメラを捕まえたスズカナ @bell_kana

ポイント。ホスティング環境（オンプレ/クラウドなど）を考慮する、Test、Dev、Productionの切り替え、馬0ジョン管理などなど。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

ポイント。ホスティング環境（オンプレ/クラウドなど）を考慮する、Test、Dev、Productionの切り替え、馬0ジョン管理などなど。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

ポイント。ホスティング環境（オンプレ/クラウドなど）を考慮する、Test、Dev、Productionの切り替え、馬0ジョン管理などなど。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

ユーザー認証はSPOFになり得る（ユーザー認証はもっともクリティカルなコンポーネント）。外部IDPへの依存が発生する。モバイルのネイティブアプリの場合、作り込みが必要（嫌ならブラウザコントロールを埋め込むとか）。ソーシャルIDPの情報は限定的。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

ユーザー認証はSPOFになり得る（ユーザー認証はもっともクリティカルなコンポーネント）。外部IDPへの依存が発生する。モバイルのネイティブアプリの場合、作り込みが必要（嫌ならブラウザコントロールを埋め込むとか）。ソーシャルIDPの情報は限定的。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

Federated Identity。自前でID管理せずに、既存のIDプロバイダを利用したい。ApplicationとIDプロバイダ間で信頼関係を結び、IDプロバイダからトークンを発行してもらう。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

『スケールインのことを忘れる人も多いが、スケールインのほうがよっぽどややこしいんです』・・・確かに。 #decode14 #RoomB

Saori Ando @sao_a

スケールインした場合にリーダーが削除された場合、どういう振る舞いにするのか考える必要がある。 #decode14 #RoomB

Saori Ando @sao_a

分散mutexは可能性は低いがSPOFになる可能性がある。Blobgがサービス不能になった場合。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

ポイント。リーダーダウン時に速やかに交代できるようにする。BLOBがSPOFになる。オートスケールによるリーダー削除の可能性を考慮する。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

リーダーはリースを定期的に更新させることで、リーダー再選出のロジックが動くようにする。 #decode14 #RoomB

Saori Ando @sao_a

Leader Election: どうやってLeaderを選出するか。IDが一番小さいインスタンスで決定などの方法もあるが、Blobのリースをmutexとして使う方法。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

Leader Election。分散処理をどう統括するか。リーダー選出の方法。インスタンスIDを提出しさせて、数値のもっとも小さいものをリーダーにする、同じBLOBのリースを獲得させてみて、獲得できたインスタンスをリーダーにする。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

ポイント。設計の初期段階で考慮しておく。負荷の検出と対処を素早く実行できるように。負荷があまりにも急激に変化する場合、オートスケーリングを使用して、常にリソースに余裕があるようにしておく。 #decode14 #RoomB

Saori Ando @sao_a

Throttlingと自動スケーリングの併用: 例えば自動スケーリング起動完了までの間だけ、Throttlingを実施させるなども可能 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

オートスケールはお金がかかる（負荷が高まるとリソース増やす）し、時間がかかる。なので、Throttlingと併用し、オートスケールを待つ間にスロットリング、なんて考え方もある。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

閾値（ソフトリミット）を決めて、閾値になると、一部の処理を中断する。キューをバッファにして、負荷を均一にしたり、優先度の低いキューを遮断したり、というやり方もある。 #decode14 #RoomB

Saori Ando @sao_a

Throttling: 急激な負荷によってサービスダウンすることをスロットリングにより守ることが必要。例えば、ソフトリミットを決定して負荷が高まってきたら処理Bだけやめて、その間は処理AとCだけ実施し、負荷が下がったら復旧する #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

Throttling。負荷の急激な増加にどう対応するか。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

キーポイント、Open時の例外処理、Harf-Openへの移行判断（定期的なPingで以降、単純なタイマー、マニュアルなど（実際はマニュアルが多い））、保護するリソースの粒度や対象の理解。 #decode14 #RoomB

Saori Ando @sao_a

Openになったらタイマーを起動して、時間がたったら状態をHalf-openにする。Half-openでtryしてみて、ある程度復旧したら、Closedに、ダメだったらOpenにまた戻す #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

Harf-Openは限定した数のみリクエストして様子を見て（XX個出してみて、連続ないしは一定数成功したら）、Closedに移行する。 #decode14 #RoomB

色違いヌメラを捕まえたスズカナ @bell_kana

ソリューションは『外部サービスの呼び出しをあきらめる』。じゃあ、いつ諦める？3つのステート。Closedが成功、Openが失敗、この中間（お試し状態）がHarf-Open。エラーが一定の上限に達するとOpenに移行し、リクエストしない。 #decode14 #RoomB

Saori Ando @sao_a

Closed = 正常 Open = 異常時 Half-Open = 正常に復旧するためのお試し状態、という3つの状態遷移 #decode14 #RoomB

Saori Ando @sao_a

Circuit Breaker 外部サービスがダウンした場合、retryが溜まっていく。溜まっていくことによりリソースが枯渇して、その他の処理へも波及してサービスダウンにつながる可能性がある。 #decode14 #RoomB