Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Qpstudy201404 インフラ設計の勘所
Ähnlich wie Qpstudy201404 インフラ設計の勘所 (20)
Mehr von Seiichiro Ishida
Mehr von Seiichiro Ishida (15)
Qpstudy201404 インフラ設計の勘所
- 1. インフラアーキテクチャ 設計の勘所 qpstudy 2014.04 @ ドワンゴセミナールーム @sechiro
- 2. せちろー (@sechiro) • qpstudyスタッフ（2010∼） • サーバ擬人化エヴァンジェリスト（2011/02∼） • 双六工場長（2011/12∼） • シャッツキステポイントカード 45枚目 • ベターホームのお料理教室 4年目 • 呉鎮守府→大湊警備府 司令部Level 76 • 昼の仕事はコンサル、SI。昨年9月に転職しました • ニコニコ動画プレミアム会員 時代の斜め先ゆく、サーバ擬人化エヴァンジェリスト Illustration by @ayakomuro
- 3. 今日話すこと • ごく普通の話 • インフラ全体設計の考え方 • なんとなくやっていることを言語化 • あくまで考え方の一例
- 4. 今日話さないこと • 新しい話 • 流行しているアーキテクチャ • アプリ設計 • 具体的な製品の選定方法 • 今期のおすすめのアニメ
- 5. オープニングポエム
- 11. 機能要件 • システムによって実現されるべき機能 • 業務システムであれば、業務要件 • 自社サービスであれば、提供サービス内容
- 12. たとえばこんな要望 • パ⃝ドラみたいなゲームつくってよ！ • Excelでやっていることを業務アプリにしたい • Amaz⃝nみたいなECサイトをつくりたい
- 14. 非機能要件 • 機能要件以外の要件、、、 • 対象システムがサービスを提供するために システム基盤側に要求される要件 • 可用性、性能、拡張性、運用性など、表 に出ている機能以外の要件 • 検討項目の洗い出しは後半で触れます
- 15. 非機能要件の例 • 24時間365日無停止 • 障害復旧は2時間以内とすること • 同時接続数増加に無停止で対応できること • 3秒以内にユーザにレスポンスを返すこと • システムリソース使用量を監視し、リソース枯渇前に アラートを上げること などなど…
- 16. 前半お疲れさまです 「厄除け！ インフラエンジニアかるた」 は、「Crystal Dew World」とのコラボによ るすべてのエンジニアのためのかるた。 水晶雫のイラストは、ライトノベルの挿絵等 で活躍されている桐野霞さんの描きおろし。 超人気声優、五十嵐裕美さんによる読み札 CDも大好評販売中！ CM https://sites.google.com/site/sgijinka/itkaruta http://suishoshizuku.com/ CrystalDiskInfo Shizuku Editionは こちらから
- 17. 要件をインフラ設計に落とす
- 19. 三つの層の基本的な役割分担 DB AP Web • クライアントとの接続を捌く • 静的なデータ配信 • 業務ロジック処理 • 動的データの生成 • データの保存と管理 • データの整合性の保証
- 20. なぜこの三層に分けるのか • 層ごとの目的に特化したSWの組み合わせ • 共通モデルを採用し、各層ごとに入替え可能に • Web: Apache Nginx • AP: Ruby on Rail/unicorn Django/gunicorn • DB: MySQL PostgreSQL
- 22. アプリ機能とインフラ設計
- 25. 「商品詳細画面」機能検討 DBAPWebブラウザ 商品詳細画面要求（商品ID） 商品ページ要求（商品ID） 商品検索（商品ID） 商品情報 商品詳細ページ 商品詳細ページ表示 商品画像取得 商品画像
- 28. 非機能要件のチェック
- 30. 「非機能要求グレード」の利用 • 「非機能要求グレード」は、IPAが公開している非機能 要件とそれを満たすモデルシステムをまとめた資料 • 非機能要件の項目が網羅されており、抜け漏れチェック のベースにできる • SI業界の標準なので、これを網羅していれば、SI的には 十分に検討したと説明できる
- 32. 「非機能要求グレード」の大項目 • 可用性 • 性能・拡張性 • 運用・保守性 • 移行性 • セキュリティ • システム環境・エコロジー
- 33. 可用性 • 24時間365日無停止 • 障害復旧は2時間以内とすること • サーバを冗長化し、SPOFを作らないこと • どのぐらいの停止は許容範囲か、トラブった時にどのぐらいの リードタイムで対応すべきかなどを検討 • 「冗長化されたサーバ群の片系だけが落ちただけなら翌営業日 対応OK」といった形で、運用コスト見合いで具体化
- 34. 性能・拡張性 • 3秒以内にユーザにレスポンスを返すこと • サービス開始当初の想定ユーザ数は⃝⃝人 • 同時接続数増加に無停止で対応できること • サーバ負荷増大時に、スケールアップ、スケールアウトのどちら で対応するかシステムアーキテクチャに応じて選択 • 個々のパーツの性能の積み上げと負荷試験から、システムの性 能とボトルネックを見積もる
- 35. 運用・保守性 • システムリソース使用量を監視し、リソー ス枯渇前にアラートを上げること • 24時間365日の保守体制を構築すること • 月に1時間の計画停止時間を設定する • サービス開始、運用体制、引き継ぎ、サービス終了のことまで考 えてシステムを設計する。教育への考慮も必要 • 構築と運用のコストはトレードオフの関係。構築コストの削減は、 運用コストに跳ね返り「運用でカバー」が必要になる
- 38. たとえば、Hadoop • 大量データ処理高速化のため、 AP(MapReduce/YARN) + DB(HDFS)を密結 合したアーキテクチャをとっている
- 42. インフラエンジニアの 説明責任
- 43. 「型」の引き出しを増やす
- 45. まとめ
- 49. 『離』
- 52. （未完）
- 53. ありがとうございました。