Qpstudy201404 インフラ設計の勘所

インフラアーキテクチャ設計の勘所 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/itkaruta http://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サイトをつくりたい

「商品詳細画面」機能検討 DBAPWebブラウザ商品詳細画面要求（商品ID）商品ページ要求（商品ID）商品検索（商品ID）商品情報商品詳細ページ商品詳細ページ表示商品画像取得商品画像

「商品注文処理」機能検討 DBAPWebブラウザ商品注文依頼（ユーザID, 商品ID）商品注文（ユーザID, 商品ID）商品在庫減（商品ID）商品購入（ユーザID）商品注文完了ページ表示処理成功商品注文完了 DB書き込みトランザクション処理が必要

もうひと頑張りです。エンジニア版人狼ゲーム、『汝はエンジニアのような名状しがたい何かなりや？』 ! 舞台は、デスマーチ末期を舞台にした猜疑心うず巻くプロジェクトルーム、あなたは果たして生き延びることができるか！？ CM https://sites.google.com/site/sgijinka/nanikanariya

非機能要件のチェック

非機能要件の検討 • 対象システムがサービスを提供するためにシステム基盤側に要求される要件 • 非機能要件は、業務要件ややりたいサービス自体から導かれるものではないため、過去設計資料などと比較して抜け漏れがないかチェックが必要

「非機能要求グレード」の利用 • 「非機能要求グレード」は、IPAが公開している非機能要件とそれを満たすモデルシステムをまとめた資料 • 非機能要件の項目が網羅されており、抜け漏れチェックのベースにできる • SI業界の標準なので、これを網羅していれば、SI的には十分に検討したと説明できる

「非機能要求グレード」の大項目 • 可用性 • 性能・拡張性 • 運用・保守性 • 移行性 • セキュリティ • システム環境・エコロジー

可用性 • 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

Qpstudy201404 インフラ設計の勘所

by Seiichiro Ishida, IT Infrastructure Engineer at home on Apr 19, 2014

Statistics

Views

Actions

1 Embed 0

Accessibility

Upload Details

Usage Rights

Report content

Qpstudy201404 インフラ設計の勘所 Presentation Transcript