qpstudy201404 インフラ設計の勘所
Post on 05-Dec-2014
15.379 Views
Preview:
DESCRIPTION
TRANSCRIPT
インフラアーキテクチャ 設計の勘所
qpstudy 2014.04 @ ドワンゴセミナールーム
@sechiro
せちろー (@sechiro)
• qpstudyスタッフ（2010～）
• サーバ擬人化エヴァンジェリスト（2011/02～）
• 双六工場長（2011/12～）
• シャッツキステポイントカード 45枚目
• ベターホームのお料理教室 4年目
• 呉鎮守府→大湊警備府 司令部Level 76
• 昼の仕事はコンサル、SI。昨年9月に転職しました • ニコニコ動画プレミアム会員
時代の斜め先ゆく、サーバ擬人化エヴァンジェリスト
Illustration by @ayakomuro
今日話すこと
• ごく普通の話 • インフラ全体設計の考え方 • なんとなくやっていることを言語化 • あくまで考え方の一例
今日話さないこと
• 新しい話 • 流行しているアーキテクチャ • アプリ設計 • 具体的な製品の選定方法 • 今期のおすすめのアニメ
オープニングポエム
「守破離」
まずは師匠に言われたこと、型を「守る」ところから修行が始まる。その後、その型を自分と照らし合わせて研究することにより、自分に合った、より良いと思われる型をつくることにより既存の型を「破る」。最終的には師匠の型、そして自分自身が造り出した型の上に立脚した個人は、自分自身と技についてよく理解しているため、型から自由になり、型から「離れ」て自在になることができる。
–Wikipedia「守破離」
今日は「型」を考えてみます
インフラ全体設計の基本的なアプローチ
どこから設計を考えますか？
インフラ設計のインプット
機能要件 非機能要件
アプリ機能 インフラ要件
インフラ要件は、機能要件から導き出されたアプリ機能と 非機能要件から決まる
機能要件
• システムによって実現されるべき機能 • 業務システムであれば、業務要件 • 自社サービスであれば、提供サービス内容
たとえばこんな要望
• パ◯ドラみたいなゲームつくってよ！ • Excelでやっていることを業務アプリにしたい
• Amaz◯nみたいなECサイトをつくりたい
アプリ機能ーECサイトの場合
商品一覧画面
顧客情報管理商品詳細画面
ユーザログイン 商品マスタ管理
購入履歴管理ショッピング カート
商品注文処理
管理機能
Amaz◯nみたいなECサイトをつくりたい
こういった機能を実装可能なインフラを検討する
非機能要件
• 機能要件以外の要件、、、 • 対象システムがサービスを提供するためにシステム基盤側に要求される要件 • 可用性、性能、拡張性、運用性など、表に出ている機能以外の要件
• 検討項目の洗い出しは後半で触れます
非機能要件の例• 24時間365日無停止
• 障害復旧は2時間以内とすること • 同時接続数増加に無停止で対応できること • 3秒以内にユーザにレスポンスを返すこと • システムリソース使用量を監視し、リソース枯渇前にアラートを上げること などなど…
前半お疲れさまです
「厄除け！ インフラエンジニアかるた」は、「Crystal Dew World」とのコラボによるすべてのエンジニアのためのかるた。 水晶雫のイラストは、ライトノベルの挿絵等で活躍されている桐野霞さんの描きおろし。超人気声優、五十嵐裕美さんによる読み札CDも大好評販売中！
CM
https://sites.google.com/site/sgijinka/itkarutahttp://suishoshizuku.com/
CrystalDiskInfo Shizuku Editionは こちらから
要件をインフラ設計に落とす
ベースは「Web三層モデル」
DBAPWeb
ベースは先人の知恵に乗っかりましょう
三つの層の基本的な役割分担
DB
AP
Web• クライアントとの接続を捌く • 静的なデータ配信
• 業務ロジック処理 • 動的データの生成
• データの保存と管理 • データの整合性の保証
なぜこの三層に分けるのか
• 層ごとの目的に特化したSWの組み合わせ • 共通モデルを採用し、各層ごとに入替え可能に
• Web: Apache ⇔ Nginx
• AP: Ruby on Rail/unicorn ⇔ Django/gunicorn
• DB: MySQL ⇔ PostgreSQL
データ管理の観点からの三層モデル
DB
AP
Web
保持データ 基本特性
静的データ 一時データ
アプリケーションコード 一時データ
データロストしても再構築可能 スケールアウト容易 負荷分散と冗長化が一体
データロストするとシステム崩壊 データ整合性確保のため分散困難 HAクラスタで冗長化
データロストしても再構築可能 スケールアウト容易 負荷分散と冗長化が一体
永続データ トランザクションデータ
可用性確保戦略の違い
永続データをDB層に集中し、データ管理を容易に
アプリ機能とインフラ設計
アプリ機能ーECサイトの場合
商品一覧画面
顧客情報管理商品詳細画面
ユーザログイン 商品マスタ管理
購入履歴管理ショッピング カート
商品注文処理
管理機能
Amaz◯nみたいなECサイトをつくりたい
アプリ機能ーECサイトの場合
商品一覧画面
顧客情報管理商品詳細画面
ユーザログイン 商品マスタ管理
購入履歴管理ショッピング カート
商品注文処理
管理機能
Amaz◯nみたいなECサイトをつくりたい
「商品詳細画面」機能検討
DBAPWebブラウザ
商品詳細画面要求（商品ID）
商品ページ要求（商品ID）商品検索（商品ID）
商品情報商品詳細ページ
商品詳細ページ表示
商品画像取得
商品画像
「商品注文処理」機能検討
DBAPWebブラウザ
商品注文依頼（ユーザID, 商品ID）
商品注文（ユーザID, 商品ID）
商品在庫減（商品ID）商品購入（ユーザID）
商品注文完了ページ表示
処理成功商品注文完了
DB書き込み
トランザクション処理が必要
もうひと頑張りです。
エンジニア版人狼ゲーム、『汝はエンジニアのような名状しがたい何かなりや？』 !舞台は、デスマーチ末期を舞台にした猜疑心うず巻くプロジェクトルーム、あなたは果たして生き延びることができるか！？
CM
https://sites.google.com/site/sgijinka/nanikanariya
非機能要件のチェック
非機能要件の検討
• 対象システムがサービスを提供するためにシステム基盤側に要求される要件
• 非機能要件は、業務要件ややりたいサービス自体から導かれるものではないため、過去設計資料などと比較して抜け漏れがないかチェックが必要
「非機能要求グレード」の利用
• 「非機能要求グレード」は、IPAが公開している非機能要件とそれを満たすモデルシステムをまとめた資料
• 非機能要件の項目が網羅されており、抜け漏れチェックのベースにできる
• SI業界の標準なので、これを網羅していれば、SI的には十分に検討したと説明できる
「非機能要求グレード」の概観こんな感じの資料
http://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html
Copyright (c) 2010-2014 IPA
「非機能要求グレード」の大項目
• 可用性 • 性能・拡張性 • 運用・保守性 • 移行性 • セキュリティ • システム環境・エコロジー
可用性
• 24時間365日無停止
• 障害復旧は2時間以内とすること
• サーバを冗長化し、SPOFを作らないこと• どのぐらいの停止は許容範囲か、トラブった時にどのぐらいのリードタイムで対応すべきかなどを検討
• 「冗長化されたサーバ群の片系だけが落ちただけなら翌営業日対応OK」といった形で、運用コスト見合いで具体化
性能・拡張性
• 3秒以内にユーザにレスポンスを返すこと • サービス開始当初の想定ユーザ数は◯◯人 • 同時接続数増加に無停止で対応できること
• サーバ負荷増大時に、スケールアップ、スケールアウトのどちらで対応するかシステムアーキテクチャに応じて選択
• 個々のパーツの性能の積み上げと負荷試験から、システムの性能とボトルネックを見積もる
運用・保守性
• システムリソース使用量を監視し、リソース枯渇前にアラートを上げること
• 24時間365日の保守体制を構築すること
• 月に1時間の計画停止時間を設定する• サービス開始、運用体制、引き継ぎ、サービス終了のことまで考えてシステムを設計する。教育への考慮も必要
• 構築と運用のコストはトレードオフの関係。構築コストの削減は、運用コストに跳ね返り「運用でカバー」が必要になる
DB
今回の採用アーキテクチャ
APWeb
APWeb
APWeb
DB RDBMS
Load Balancer
HAクラスタ
スケールアウト
監視 サーバ
Web三層モデルを崩す時 ー『破』の例
たとえば、Hadoop
• 大量データ処理高速化のため、AP(MapReduce/YARN) + DB(HDFS)を密結合したアーキテクチャをとっている
基本を押さえれば応用も自由
• 用途によって、三層モデルの利点を捨ててもよい
• ただし、なぜ、そのアーキテクチャを選んだか説明できるように
• 基本を押さえてこその「破」
なぜ、その設計なのか 説明できることが重要
–室見立華
“私言ったわよね、一からコンフィグを作れって”
夏海公司『なれる！ SE』第1巻より
インフラエンジニアの 説明責任
「型」の引き出しを増やす
インフラのデザインパターン
AWSクラウドデザインパターンとか
!
http://aws.clouddesignpattern.org/
まとめ
インフラ設計のインプット
機能要件 非機能要件
アプリ機能 インフラ要件
インフラ要件は、機能要件から導き出されたアプリ機能と 非機能要件から決まる
基本は「Web三層モデル」
DBAPWeb
DB
今回の採用アーキテクチャ
APWeb
APWeb
APWeb
DB RDBMS
Load Balancer
HAクラスタ
スケールアウト
監視 サーバ
『離』
「守破離」
まずは師匠に言われたこと、型を「守る」ところから修行が始まる。その後、その型を自分と照らし合わせて研究することにより、自分に合った、より良いと思われる型をつくることにより既存の型を「破る」。最終的には師匠の型、そして自分自身が造り出した型の上に立脚した個人は、自分自身と技についてよく理解しているため、型から自由になり、型から「離れ」て自在になることができる。
–Wikipedia「守破離」
–菊川仁義
“オレはようやくのぼりはじめたばかりだからな
このはてしなく遠い男坂をよ…”
車田正美『男坂』最終話より
（未完）
ありがとうございました。
Q&A
Twitterでなんの前触れもなく始まった『インフラエンジニア双六』を基にしたボードゲーム。 !遊びながら、楽しくインフラエンジニアの生き様を体験することができます。職場の新人教育にいかがでしょうか。
CM
https://sites.google.com/site/sgijinka/sugoroku
Special Thanks
今回は、Keynote のだいたいいい感じになるテンプレート「Azusa」を使用させていただきました。ありがとうございました。 !「Azusa」紹介URL
http://memo.sanographix.net/post/82160791768
top related