Downloaded 131 times
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.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11. 機能要件 • システムによって実現されるべき機能 • 業務システムであれば、業務要件 •自社サービスであれば、提供サービス内容
- 12. たとえばこんな要望 • パ⃝ドラみたいなゲームつくってよ！ • Excelでやっていることを業務アプリにしたい •Amaz⃝nみたいなECサイトをつくりたい
- 13.
- 14. 非機能要件 • 機能要件以外の要件、、、 • 対象システムがサービスを提供するために システム基盤側に要求される要件 •可用性、性能、拡張性、運用性など、表 に出ている機能以外の要件 • 検討項目の洗い出しは後半で触れます
- 15. 非機能要件の例 • 24時間365日無停止 • 障害復旧は2時間以内とすること •同時接続数増加に無停止で対応できること • 3秒以内にユーザにレスポンスを返すこと • システムリソース使用量を監視し、リソース枯渇前に アラートを上げること などなど…
- 16. 前半お疲れさまです 「厄除け！ インフラエンジニアかるた」 は、「Crystal DewWorld」とのコラボによ るすべてのエンジニアのためのかるた。 水晶雫のイラストは、ライトノベルの挿絵等 で活躍されている桐野霞さんの描きおろし。 超人気声優、五十嵐裕美さんによる読み札 CDも大好評販売中！ CM https://sites.google.com/site/sgijinka/itkaruta http://suishoshizuku.com/ CrystalDiskInfo Shizuku Editionは こちらから
- 17.
- 18.
- 19. 三つの層の基本的な役割分担 DB AP Web • クライアントとの接続を捌く • 静的なデータ配信 •業務ロジック処理 • 動的データの生成 • データの保存と管理 • データの整合性の保証
- 20. なぜこの三層に分けるのか • 層ごとの目的に特化したSWの組み合わせ • 共通モデルを採用し、各層ごとに入替え可能に •Web: Apache Nginx • AP: Ruby on Rail/unicorn Django/gunicorn • DB: MySQL PostgreSQL
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30. 「非機能要求グレード」の利用 • 「非機能要求グレード」は、IPAが公開している非機能 要件とそれを満たすモデルシステムをまとめた資料 • 非機能要件の項目が網羅されており、抜け漏れチェック のベースにできる •SI業界の標準なので、これを網羅していれば、SI的には 十分に検討したと説明できる
- 31.
- 32. 「非機能要求グレード」の大項目 • 可用性 • 性能・拡張性 •運用・保守性 • 移行性 • セキュリティ • システム環境・エコロジー
- 33. 可用性 • 24時間365日無停止 • 障害復旧は2時間以内とすること •サーバを冗長化し、SPOFを作らないこと • どのぐらいの停止は許容範囲か、トラブった時にどのぐらいの リードタイムで対応すべきかなどを検討 • 「冗長化されたサーバ群の片系だけが落ちただけなら翌営業日 対応OK」といった形で、運用コスト見合いで具体化
- 34. 性能・拡張性 • 3秒以内にユーザにレスポンスを返すこと • サービス開始当初の想定ユーザ数は⃝⃝人 •同時接続数増加に無停止で対応できること • サーバ負荷増大時に、スケールアップ、スケールアウトのどちら で対応するかシステムアーキテクチャに応じて選択 • 個々のパーツの性能の積み上げと負荷試験から、システムの性 能とボトルネックを見積もる
- 35. 運用・保守性 • システムリソース使用量を監視し、リソー ス枯渇前にアラートを上げること • 24時間365日の保守体制を構築すること •月に1時間の計画停止時間を設定する • サービス開始、運用体制、引き継ぎ、サービス終了のことまで考 えてシステムを設計する。教育への考慮も必要 • 構築と運用のコストはトレードオフの関係。構築コストの削減は、 運用コストに跳ね返り「運用でカバー」が必要になる
- 36.
- 37.
- 38. たとえば、Hadoop • 大量データ処理高速化のため、 AP(MapReduce/YARN) +DB(HDFS)を密結 合したアーキテクチャをとっている
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.