Qpstudy201404 インフラ設計の勘所

18,497 views

Published on

0 Comments
57 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
18,497
On SlideShare
0
From Embeds
0
Number of Embeds
7,127
Actions
Shares
0
Downloads
119
Comments
0
Likes
57
Embeds 0
No embeds

No notes for slide

Qpstudy201404 インフラ設計の勘所

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

×