qpstudy 2014.04 ミドルウェア設計の勘所
Download as PPTX, PDF53 likes21,407 views
qpstudy 2014.04 ミドルウェア設計の勘所
qpstudy 2014.04 ミドルウェア設計の勘所
- 3. Who are you, @nekoruri ? 秋葉原生まれ大手町育ちの歌って踊れる 江戸っ子インフラエンジニア。 0と1が紡ぐ「ゆるやかなつながり」に魅せられ早20年、 SNSとCGMの力で世界を幸福にするのがライフワーク。 市民、幸福は義務です。あなたは幸福ですか？ http://twitter.com/nekoruri http://facebook.com/masapon http://d.hatena.ne.jp/nekoruri/
- 8. 「ミドルウェア」 ？
- 12. おさらい：Web三層モデル Web AP DB • クライアント との接続を捌 く • 静的なデータ 配信 • 業務ロジック 処理 • 動的データの 生成 • データの保存 と管理 • データの整合 性の保証
- 13. ミドルウェアの範囲 Web AP DB ハード ウェア ハード ウェア ハード ウェア OS OS OS Web サーバ AP サーバ DB サーバ アプリ ケーション
- 14. ミドルウェアの範囲 Web AP DB ハード ウェア ハード ウェア ハード ウェア OS OS OS アプリ ケーション Web サーバ AP サーバ DB サーバ
- 15. ミドルウェアの範囲 Web AP DB ハード ウェア ハード ウェア ハード ウェア OS OS OS アプリ ケーション Web サーバ AP サーバ DB サーバ ハードウェア、OS、アプリケーション以外の すべて
- 16. アプリケーション Web AP DB ハード ウェア ハード ウェア ハード ウェア OS OS OS アプリ ケーション Web サーバ AP サーバ DB サーバ ビジネスの価値そのもの
- 17. アプリケーション Web AP DB ハード ウェア ハード ウェア ハード ウェア OS OS OS アプリ ケーション Web サーバ AP サーバ DB サーバ ビジネスの価値そのもの 機能要件 ⇒ アプリの機能
- 18. ミドルウェアの範囲 Web AP DB ハード ウェア ハード ウェア ハード ウェア OS OS OS アプリ ケーション Web サーバ AP サーバ DB サーバ ハードウェア、OS、アプリケーション以外の すべて
- 22. ミドルウェアの選択
- 23. ミドルウェアの選択 1. 機能要件によるもの 1. 非機能要件によるもの ○○がしたい ⇒ その実現に□□が最適 障害復旧は××時間以内にしたい ⇒ その実現に△△が最適
- 24. 今回の採用アーキテクチャ Load Balancer Web AP Web AP Web AP DB DB 監視 サーバ スケールアウト HAクラス タ
- 25. 今回の採用アーキテクチャ Load Balancer Web AP Web AP Web AP DB DB 監視 サーバ スケールアウト HAクラス タ ① ② ③
- 26. 今回の採用アーキテクチャ Load Balancer Web AP Web AP Web AP DB DB 監視 サーバ スケールアウト HAクラス タ ① ② ③
- 27. Web+AP層のインフラ設計 • 保持データ – Web: 静的データ、一時データ – AP: アプリケーションコード、一時データ • 基本特性 – データロストしても再構築可能 – スケールアウト容易 – 負荷分散と冗長化が一体
- 28. APサーバの役割 • アプリケーションを動かす – 業務ロジック処理 – 動的データの生成 • 何らかの言語によるプログラムを動かす – Webからのリクエストに応える – 必要に応じてDBにアクセスする
- 29. APサーバの選択 • 言語環境による縛り（機能要件） ⇒ 言語ごとのAPサーバ – Java: Tomcat, Glassfish, Jetty – Ruby: Unicorn, Puma, Phusion Passenger – PHP: mod_php5, php-fpm – Perl: Starman, Twiggy, mod_perl
- 30. APサーバの選択？ • 言語環境による縛り（機能要件） ⇒ 言語ごとのAPサーバ – Java: Tomcat, Glassfish, Jetty – Ruby: Unicorn, Puma, Phusion Passenger – PHP: mod_php5, php-fpm – Perl: Starman, Twiggy, mod_perl • Webサーバ(Apache, nginx) の一部となっ て動くAPサーバがある ⇒ 実質的にWebサーバの選択も縛る
- 31. Webサーバの役割 • クライアントとの接続を捌く – 時間の掛かる処理のAPサーバ応答待ち • 静的なデータ配信 – 3G回線のスマホがちんたら長時間接続 ⇒ 豊富な同時接続数 – LAN接続のPCが大量の画像を取得 ⇒ 高速なスループット
- 32. C10K（同時接続数の爆発）問題 • 大量のクライアントからの同時接続 – 何も考えないApache(prefork設定)では無理 – nginxやApache event_mpmの検討 • node.jsでAPサーバを直に公開 – 非同期モデルならば直接C10Kが扱える – 静的データは別ドメインのWebサーバ
- 33. HTTP KeepAlive • ブラウザーWeb間は有効が望ましい – TCPやSSLのハンドシェークにかかる時間 – TCP接続中のパケット落ちのリカバリ時間 （1秒〜3秒） ⇒ スループットに影響 • WebーAP間は無効が望ましい – KeepAlive = 処理が終わった後も接続を残す – APサーバの同時接続数を無駄に消費
- 34. Web+AP層のインフラ設計 • 保持データ – Web: 静的データ、一時データ – AP: アプリケーションコード、一時データ • 基本特性 – データロストしても再構築可能 – スケールアウト容易 – 負荷分散と冗長化が一体
- 35. Web+AP層はStatelessに保つ • データを持たない – データは全てDBに保存 – ログも全てDB等に送信 • データの同期なくサーバを追加できる – 非機能要件：性能・拡張性 同時接続数増加に無停止で対応できること • いつサーバが壊れてもなにも失わない
- 36. 今回の採用アーキテクチャ Load Balancer Web AP Web AP Web AP DB DB 監視 サーバ スケールアウト HAクラス タ ① ② ③
- 37. DB層のインフラ設計 • 保持データ – 永続データ – トランザクションデータ • 基本特性 – データロストするとシステム崩壊 – データ整合性確保のため分散困難 – HAクラスタで冗長化
- 38. DB層のインフラ設計 • 保持データ – 永続データ – トランザクションデータ • 基本特性 – データロストするとシステム崩壊 – データ整合性確保のため分散困難 – HAクラスタで冗長化 死ぬ気でデータを守れ
- 39. HAクラスタ • DBサーバの冗長化手法の一つ – 複数台（通常は2台）でペアを組む – 通常はその片方（サーバA）が仕事をする – もう片方（サーバB）は仕事をしない代わり に、サーバAが動いているか延々とチェック – サーバAが突然の死 – サーバBがAの死に気付く – サーバBが仕事を始める 10分程度
- 40. データの同期 • Shared disk model – ハードウェアレベルで高度に冗長化された 頑丈な共有ディスクにA/Bともに接続 – サーバAが死んだらサーバBが読みに行く サーバA サーバB
- 41. データの同期 • Shared nothing model – サーバAは、処理の結果変更された内容を ずっとサーバBに送り続ける – 十分に速ければ、サーバAと同じデータを サーバB上でも持っていることになる サーバA サーバB
- 42. ボトルネックとの闘い • CAP定理：以下の3つは両立しない 1. 一貫性 2. 可用性 3. 分断耐性 • 一般的なDBでざっくりいうと 1. 一貫性と 2. 可用性を求めると、 3. 複数台に分散させることができない
- 43. CAP定理の抜け道 • どうしても1台じゃ厳しいヽ(;´Д`)ﾉ – キャッシュ、レプリケーション ⇒ 一貫性への影響 – 機能分割（機能分割）、水平分割 ⇒ 開発効率や一貫性への影響 – 一貫性を捨て、結果整合性で妥協 ⇒ 分散DBの活用
- 44. 分散DB（NoSQL）の活用 • 「サーバを増やすほど速くなる」 – そんな銀の弾丸があったらOracleが買収し(略 • 分散DBの「性質」を深く理解 – どんなアクセスに向いているのか – どんなデータに向いているのか – 合わないものを使うと不幸になります(断言)
- 45. 今回の採用アーキテクチャ Load Balancer Web AP Web AP Web AP DB DB 監視 サーバ スケールアウト HAクラス タ ① ② ③
- 46. 監視サーバの役割 1. 障害の発見、通知 – サービスの「生存」を監視、通知 – 冗長化サーバの一部だけの故障も検知 2. メトリクス（リソース状況等）の取得 – CPUやメモリの利用率 – ディスク空き容量 – レスポンスを返し終わるまでの応答時間 – どうもおかしい＝閾値を超えたら通知
- 47. ボトルネックの把握 • 様々なメトリクスの取得 – リクエスト数、ネットワークトラフィック – DBの内部パラメータ ⇒ ボトルネックの把握、解消
- 48. ボトルネックの把握 • 様々なメトリクスの取得 – リクエスト数、ネットワークトラフィック – DBの内部パラメータ ⇒ ボトルネックの把握、解消 推測するな 計測せよ
- 49. 監視ツールの選択 • 生存監視 – Nagios、Mon、Sensu • メトリクス取得 – Munin、GrowthForecast、Cacti • 統合監視 – Zabbix
- 50. 監視ツールの選択 • 生存監視 – Nagios、Mon、Sensu • メトリクス取得 – Munin、GrowthForecast、Cacti • 統合監視 – Zabbix とにかく手軽 必要な機能が揃っている
- 52. ミドルウェアと生きる
- 53. インフラエンジニアの主戦場 • 下の層は手を動かすことが減った – ハードウェアの仮想化 – OSはRHEL/CentOS、Ubuntuに集約 • 最もエキサイティングな分野 – 新しいミドルウェアが毎年いくつも登場 – 性質を見抜き、最適な場所に投入 – ソフトウェア単位では数年で陳腐化
- 54. どうすればこの先生きのこれるか
- 55. どうすればこの先生きのこれるか • 人は考えることに注力しよう！ – 利用できることは利用しよう • IaaS、PaaS、BaaS • AWS等クラウド事業者の提供するコンポーネント – 自動化できることは自動化しよう • Puppet、Chef • Vagrant • 継続的デリバリー – 抽象化できることは抽象化しよう • IaaS • Docker
- 56. どうすればこの先生きのこれるか • ミドルウェアの「性質」をつかもう！ – データベースとか分散DBとかMQとか • 得意とするデータの形式 • 更新の方法・頻度、取得の方法・頻度 • ボトルネックはどこか – WebサーバとかAPサーバとか • キャッシュ • 接続の管理方法 • SSLアクセラレーション – 最適な場所に最適なものを！パズル！
- 57. どうすればこの先生きのこれるか • コンピュータサイエンスを学ぼう！ – 基礎を知っている人は強い – 新しいものが出てもすぐに順応できる – むしろ余計なことを覚えずに済む – 経験に理詰めを加えることで最強に見える 「推測するな、計測せよ」 １．経験から仮説をたてる ２．計測する ３．結果をもとに理詰めで対策する
- 58. どうすればこの先生きのこれるか • セキュリティの知識をつけよう – 情報セキュリティと、暗号化技術 – 脆弱性のリスク分析ができる – 私たちは、 何を 何から どのように 守りたいのか？
- 60. The Heartbleed Bug CVE-2014-0160 TLS heartbeat read overrun 2014-04-07(現地時刻) 脆弱性公表 2014-04-08 JPCERT/CC等から注意喚起 2014-04-13 OpenBSDチームがfork開始 2014-04-19 国内被害公表(三菱UFJニコス) http://www.cr.mufg.jp/corporate/info/pdf/2014/140418_01.pdf
- 61. The Heartbleed Bug CVE-2014-0160 TLS heartbeat read overrun 2014-04-07(現地時刻) 脆弱性公表 2014-04-08 JPCERT/CC等から注意喚起 2014-04-13 OpenBSDチームがfork開始 2014-04-19 国内被害公表(三菱UFJニコス) http://www.cr.mufg.jp/corporate/info/pdf/2014/140418_01.pdf
- 62. どうすればこの先生きのこれるか • セキュリティの知識をつけよう – 情報セキュリティと、暗号化技術 – 脆弱性のリスク分析ができる – 私たちは、セキュリティ技術を使って 何を 何から どのように 守りたいのか？
- 63. どうすればこの先生きのこれるか • 新しい情報へのアンテナを張り続けよう – 新しい脆弱性 • 極めて緊急性の高い脆弱性にもすぐ対応できる • 読み解くためにはセキュリティの知識が必須 • Heartbleedでも詳細解説出るには数日 – 新しい技術、ソフトウェア • 「使ってみた」系記事 • 「どう使ってみたい」系記事 • 公式ドキュメント、GitHub
- 66. !?
- 67. どうすればこの先生きのこれるか • 新しい情報へのアンテナを張り続けよう – 新しい脆弱性 • 極めて緊急性の高い脆弱性にもすぐ対応できる • 読み解くためにはセキュリティの知識が必須 • Heartbleedでも詳細解説出るには数日 – 新しい技術、ソフトウェア • 「使ってみた」系記事 • 「どう使ってみたい」系記事 • 公式ドキュメント、GitHub – 急に流行が来ても、嗅覚が効く。
- 68. どうすればこの先生きのこれるか • 情報交換をしよう – ブログを書こう • 突っ込まれる──だがそれが良い。 • リファラー見てニヤニヤできる。 – 技術の話ができる相手を見つけよう • Twitter、Facebook • エンジニア勉強会、セミナー、展示会 – 懇親会も機会の一つ • ちょっとウザイぐらいでも絡んで行っちゃおう • Twitterとかでも絡めるようになれば勝ち
- 70. まとめ • 「ミドルウェア」ってなによ？ – OSとアプリケーションの間のすべて • Web3層モデルで何考えればいいの？ – Web+APの中にデータを持たない – DBのデータを気合いで守る – 推測するな、計測せよ • ミドルウェアと付き合っていこう – 積極的に勉強しよう、アンテナ張ろう、 話し合おう！