第2回 クラウドデザインパターン勉強会 #jazug (2014/08/20)

http://jazug.doorkeeper.jp/events/13964 ・2014-08-20(水)19:30 - 21:50 ・イベント概要 7/30 の 第1回 クラウドデザインパターン勉強会 の好評を受け、第2回を開催します 今回2回目は、Compute Partitioning ガイダンスと、補正トランザクションを中心にいくつかのパターンを紹介します。 続きを読む
4
前へ 1 2 ・・ 5 次へ
hy0shi0ka @hy0shi0ka

分割とは=論理的な分割、フロントのWebサイト、管理用のWebサイト等 #jazug

2014-08-20 19:54:46
Jun Yokochi @JunYokochi

JAZUG CDP勉強会第二回クラウドデザインパターン超入門=「コンピューティングの分割、配置」 「オートスケーリング」 slideshare.net/k1hash/cdp-381… @SlideShareさんから

2014-08-20 19:57:34
s.hiruta @web_se

Azure のアイコン集。AWSのSimple IconのAzure版てところ。microsoft.com/en-us/download… #jazug

2014-08-20 19:57:36
レベル100のクワッスを連れ歩くスズカナ @bell_kana

論理的な分割その2(フロント側の細分化):キャッシュが有効なページ(キャッシュもアプリ全体、ユーザー別(レコメンドみたいな))、キャッシュが無効なページとか、処理負荷の高いページ、なんて分割したりする。 #jazug

2014-08-20 19:58:28
レベル100のクワッスを連れ歩くスズカナ @bell_kana

フロントエンドの商品紹介のページ(キャッシュ有効)、買い物カート(キャッシュ効かせにくい)、検索(高負荷、非キャッシュ)のように分割する。その上で、IISのARR(URLrewrite)で同一URLで稼働するインスタンスを分ける。 #jazug

2014-08-20 20:01:04
レベル100のクワッスを連れ歩くスズカナ @bell_kana

コンピューティングとかキャッシュとか、ストレージとかDBとか、そもそもクラウドのサービス自体がわかれていたりするので、クラウドにおける論理的な分割は慣れればやりやすかったりする。 #jazug

2014-08-20 20:02:27
レベル100のクワッスを連れ歩くスズカナ @bell_kana

ただ、単に分割しましょってだけでなく、ここに非機能要件を追加して分割する。非機能要件の例として、可用性、性能/拡張性、運用/保守性、セキュリティ、移行性、システム環境/エコロジーなど。 #jazug

2014-08-20 20:04:15
hy0shi0ka @hy0shi0ka

可用性ーAzureの場合、コンピューティングサービスで可用性の担保が異なる。 #jazug

2014-08-20 20:09:26
レベル100のクワッスを連れ歩くスズカナ @bell_kana

サービスによって可用性の担保(単一インスタンスでも可用性を担保するWebサイト、2インスタンス以上用意して可用性が保障されるクラウドサービスとか)が異なるので注意しましょう。 #jazug

2014-08-20 20:10:21
レベル100のクワッスを連れ歩くスズカナ @bell_kana

性能向上のためには、オートスケール(主にサーバーの台数を増やすスケールアウト)に加えて、キャッシュやCDN、ストレージなどの各サービスを効果的に使いましょう。 #jazug

2014-08-20 20:12:31
レベル100のクワッスを連れ歩くスズカナ @bell_kana

分割した各コンポーネントに対して、適切なインスタンスサイズ(A0~A9まで)を選択しましょう。その上で、インスタンス数はオートスケールを使って、適切に増減させましょう。 #jazug

2014-08-20 20:14:21
レベル100のクワッスを連れ歩くスズカナ @bell_kana

分割の入り口としては、外部のサービスを呼んでいる部分を切り出すのが簡単。他にも、同じアップデート周期を持つコンポーネントでグループ化すると管理しやすい。 #jazug

2014-08-20 20:16:34
レベル100のクワッスを連れ歩くスズカナ @bell_kana

コンポーネントを分割しまくって、別のインスタンスに配置すると、コストが上がりやすい。また自動化などをするとしても、管理対象は増える。バランス大事。 #jazug

2014-08-20 20:19:33
レベル100のクワッスを連れ歩くスズカナ @bell_kana

論理的にいろいろ分割できるけど、非機能要件を考えて、分割するしないを決めるっていうのも一つの考え方。 #jazug

2014-08-20 20:20:59
レベル100のクワッスを連れ歩くスズカナ @bell_kana

デプロイや更新の切り口でコンピューティングの分割を考慮するってのは結構役に立った、とのこと。 #jazug

2014-08-20 20:23:28
レベル100のクワッスを連れ歩くスズカナ @bell_kana

オートスケールの話!スケール要因を設定する。レスポンス時間、キューの長さ、CPUやメモリの使用率など。閾値を設定し、これを評価することで、インスタンス数の増減が行われる。 #jazug

2014-08-20 20:25:51
レベル100のクワッスを連れ歩くスズカナ @bell_kana

オートスケールで考慮すべきことは、スケールの頻度。頻度が多すぎるとシステムが不安定になる。極端な話、インスタンスを減らすことに関しては手動でもイイという考え方もある。 #jazug

2014-08-20 20:27:18
hy0shi0ka @hy0shi0ka

自動スケールの検討事項「頻度」 #jazug

2014-08-20 20:27:35
赤提灯 @akachochin

非機能要件はそのままクラウドを使う理由に成りうる。言われてみれば、確かにその通りだ。この一言だけで今日ここに来た甲斐がある。 #jazug

2014-08-20 20:27:58
hy0shi0ka @hy0shi0ka

イミュータブル・インフラストラクチャー:不変なインフラストラクチャー。一度サーバを作成したら構成変更を加えない。 #jazug

2014-08-20 20:29:57
レベル100のクワッスを連れ歩くスズカナ @bell_kana

オートスケールの考慮点。「長時間タスク」への対応。長時間タスク中に、そのインスタンスが削除対象になる可能性がある。スケールの途中でデータが失われないように、チェックポイントを設けたり、分割したりしよう。 #jazug

2014-08-20 20:30:41
レベル100のクワッスを連れ歩くスズカナ @bell_kana

「スケールユニット」の考え方。例えば、1万ユーザー増えましたってときに、Webサイトを1インスタンス増やすだけじゃなく、実はバックグラウンドのワーカーロールも増やさなきゃだった、みたいなスケールのまとまり。 #jazug

2014-08-20 20:32:53
s.hiruta @web_se

ポータルもよく出来ているが、Azure Management Library C#とかで自前でコーディングも可能。AWS CLIみたいなものか。 #jazug

2014-08-20 20:34:14
masak1yu🐧 @masak1yu

ソシャゲーとかだったら必須だけども。。。(オートスケール #jazug

2014-08-20 20:35:55
前へ 1 2 ・・ 5 次へ