qpstudy 2014.04ミドルウェア設計の勘所

qpstudy 2014-04-19@nekoruri

Who are you, @nekoruri ?

秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア。0 と 1 が紡ぐ「ゆるやかなつながり」に魅せられ早 20 年、

SNS と CGM の力で世界を幸福にするのがライフワーク。市民、幸福は義務です。あなたは幸福ですか？

http://twitter.com/nekoruri

http://facebook.com/masapon

http://d.hatena.ne.jp/nekoruri/

IaaS システム構築 / 管理ガイド

第 4 章 クラウド環境の運用における監視と可視化　・安定運用のための運用監視　・運用監視の方法　・ニフティクラウドと OS の標準機能で　　サーバー監視　・ Munin でかんたんリソース監視　・統合監視ツール Zabbix による監視基盤　　の構築　　・その他の監視ツール　・メトリクス収集・解析サービス　・クラウドと監視と DevOps

最近流行の OpenSSL まとめ記事の中の

人

なかやま　まさひろ

アメーバ事業本部クロスイノベーション室

Ameba 全体の「横軸」改善チーム・ゲーム共通のランキング・サービス間の回遊

「ミドルウェア」

？

「ミドルウェア」

コンピュータの基本的な制御を行うオペレーティングシステム

(OS) と、各業務処理を行うアプリケーションソフトウェアと

の中間に入るソフトウェアhttp://ja.wikipedia.org/wiki/ ミドルウェア

「ミドルウェア」

コンピュータの基本的な制御を行うオペレーティングシステム

(OS) と、各業務処理を行うアプリケーションソフトウェアと

の中間に入るソフトウェアhttp://ja.wikipedia.org/wiki/ ミドルウェア

おさらい： Web 三層モデル

Web AP DB

おさらい： Web 三層モデル

Web AP DB

• クライアントとの接続を捌く

• 静的なデータ配信

• 業務ロジック処理

• 動的データの生成

• データの保存と管理

• データの整合性の保証

ミドルウェアの範囲

Web AP DB

ハードウェア

ハードウェア

ハードウェア

OS OS OS

Webサーバ

APサーバ

DBサーバ

アプリケーション

ミドルウェアの範囲

Web AP DB

ハードウェア

ハードウェア

ハードウェア

OS OS OS

アプリケーションWeb

サーバAP

サーバ

DBサーバ

ミドルウェアの範囲

Web AP DB

ハードウェア

ハードウェア

ハードウェア

OS OS OS

アプリケーションWeb

サーバAP

サーバ

DBサーバ

ハードウェア、 OS 、アプリケーション以外の

すべて

アプリケーション

Web AP DB

ハードウェア

ハードウェア

ハードウェア

OS OS OS

アプリケーションWeb

サーバAP

サーバ

DBサーバ

ビジネスの価値そのもの

アプリケーション

Web AP DB

ハードウェア

ハードウェア

ハードウェア

OS OS OS

アプリケーションWeb

サーバAP

サーバ

DBサーバ

ビジネスの価値そのもの機能要件　⇒　アプリの機能

ミドルウェアの範囲

Web AP DB

ハードウェア

ハードウェア

ハードウェア

OS OS OS

アプリケーションWeb

サーバAP

サーバ

DBサーバ

ハードウェア、 OS 、アプリケーション以外の

すべて

ミドルウェア＝OS の上で

アプリケーションを動かすために必要なすべてのソフトウェア

ミドルウェアの設計＝アプリケーションを動かすために

必要なすべてのソフトウェアを「どのように」

組み合わせるか決める

ミドルウェアの設計＝

アプリケーションを動かすために必要なすべてのソフトウェアを

「どのように」組み合わせるか決める

要件を満たすシステムを作る

ミドルウェアの選択

ミドルウェアの選択1. 機能要件によるもの

2. 非機能要件によるもの

○○ がしたい　　　　⇒ その実現に□□が最適

障害復旧は ×× 時間以内にしたい　　　　⇒ その実現に△△が最適

今回の採用アーキテクチャ

LoadBalancer

Web AP

Web AP

Web AP

DBDB

監視サーバ

スケールアウト

HA クラスタ

今回の採用アーキテクチャ

LoadBalancer

Web AP

Web AP

Web AP

DBDB

監視サーバ

スケールアウト

HA クラスタ

①

②

③

今回の採用アーキテクチャ

LoadBalancer

Web AP

Web AP

Web AP

DBDB

監視サーバ

スケールアウト

HA クラスタ

①

②

③

Web+AP 層のインフラ設計• 保持データ–Web:静的データ、一時データ– AP: アプリケーションコード、一時

データ

• 基本特性– データロストしても再構築可能– スケールアウト容易– 負荷分散と冗長化が一体

AP サーバの役割• アプリケーションを動かす– 業務ロジック処理– 動的データの生成

• 何らかの言語によるプログラムを動かす–Web からのリクエストに応える– 必要に応じて DB にアクセスする

AP サーバの選択• 言語環境による縛り（機能要件）

　　　　　　⇒ 言語ごとの APサーバ– Java:Tomcat, Glassfish, Jetty– Ruby: Unicorn, Puma, Phusion

Passenger– PHP: mod_php5, php-fpm– Perl: Starman, Twiggy, mod_perl

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 サーバの選択も縛る

Web サーバの役割• クライアントとの接続を捌く– 時間の掛かる処理の AP サーバ応答待ち

• 静的なデータ配信– 3G 回線のスマホがちんたら長時間接続

　　　　　　　　　⇒ 豊富な同時接続数– LAN 接続の PC が大量の画像を取得

　　　　　　　　　⇒ 高速なスループット

C10K（同時接続数の爆発）問題

• 大量のクライアントからの同時接続–何も考えない Apache(prefork 設定 ) では無

理– nginx や Apache event_mpm の検討

• node.js で AP サーバを直に公開– 非同期モデルならば直接 C10K が扱える– 静的データは別ドメインの Web サーバ

HTTP KeepAlive

• ブラウザー Web 間は有効が望ましい– TCP や SSL のハンドシェークにかかる時間– TCP 接続中のパケット落ちのリカバリ時間（ 1秒〜 3秒）

　　　　　　　　　⇒ スループットに影響

• Web ー AP 間は無効が望ましい– KeepAlive = 処理が終わった後も接続を残す– AP サーバの同時接続数を無駄に消費

Web+AP 層のインフラ設計• 保持データ–Web:静的データ、一時データ– AP: アプリケーションコード、一時

データ

• 基本特性– データロストしても再構築可能– スケールアウト容易– 負荷分散と冗長化が一体

Web+AP 層は Stateless に保つ

• データを持たない– データは全て DB に保存– ログも全て DB等に送信

• データの同期なくサーバを追加できる– 非機能要件：性能・拡張性同時接続数増加に無停止で対応できること

• いつサーバが壊れてもなにも失わない

今回の採用アーキテクチャ

LoadBalancer

Web AP

Web AP

Web AP

DBDB

監視サーバ

スケールアウト

HA クラスタ

①

②

③

DB 層のインフラ設計• 保持データ–永続データ– トランザクションデータ

• 基本特性– データロストするとシステム崩壊– データ整合性確保のため分散困難– HA クラスタで冗長化

DB 層のインフラ設計• 保持データ–永続データ– トランザクションデータ

• 基本特性– データロストするとシステム崩壊– データ整合性確保のため分散困難– HA クラスタで冗長化

死ぬ気でデータを守れ

HA クラスタ• DB サーバの冗長化手法の一つ–複数台（通常は 2台）でペアを組む– 通常はその片方（サーバ A）が仕事をする– もう片方（サーバ B）は仕事をしない代わり

に、サーバ A が動いているか延々とチェック– サーバ A が突然の死– サーバ B が A の死に気付く– サーバ B が仕事を始める

10 分程度

データの同期• Shared disk model– ハードウェアレベルで高度に冗長化された頑丈な共有ディスクに A/B ともに接続

– サーバ A が死んだらサーバ B が読みに行く

サーバ A サーバ B

データの同期• Shared nothing model– サーバ A は、処理の結果変更された内容をずっとサーバ B に送り続ける

–十分に速ければ、サーバ A と同じデータをサーバ B 上でも持っていることになる

サーバ A サーバ B

ボトルネックとの闘い• CAP 定理：以下の 3 つは両立しない

1. 一貫性2. 可用性3. 分断耐性

• 一般的な DB でざっくりいうと1. 一貫性と2. 可用性を求めると、3. 複数台に分散させることができない

CAP 定理の抜け道• どうしても 1台じゃ厳しいヽ (;´Д`) ﾉ– キャッシュ、レプリケーション

　　⇒ 一貫性への影響– 機能分割（機能分割）、水平分割

　　⇒ 開発効率や一貫性への影響– 一貫性を捨て、結果整合性で妥協

　　⇒ 分散 DB の活用

分散 DB（ NoSQL）の活用• 「サーバを増やすほど速くなる」– そんな銀の弾丸があったら Oracle が買収し

(略

• 分散 DB の「性質」を深く理解–どんなアクセスに向いているのか–どんなデータに向いているのか– 合わないものを使うと不幸になります (断言 )

今回の採用アーキテクチャ

LoadBalancer

Web AP

Web AP

Web AP

DBDB

監視サーバ

スケールアウト

HA クラスタ

①

②

③

監視サーバの役割1. 障害の発見、通知– サービスの「生存」を監視、通知– 冗長化サーバの一部だけの故障も検知

2. メトリクス（リソース状況等）の取得– CPU やメモリの利用率– ディスク空き容量– レスポンスを返し終わるまでの応答時間– どうもおかしい＝閾値を超えたら通知

ボトルネックの把握• 様々なメトリクスの取得– リクエスト数、ネットワークトラフィック– DB の内部パラメータ

　　　　　⇒ ボトルネックの把握、解消

ボトルネックの把握• 様々なメトリクスの取得– リクエスト数、ネットワークトラフィック– DB の内部パラメータ

　　　　　⇒ ボトルネックの把握、解消

推測するな計測せよ

監視ツールの選択• 生存監視– Nagios 、 Mon 、 Sensu

• メトリクス取得–Munin 、 GrowthForecast 、 Cacti

• 統合監視– Zabbix

監視ツールの選択• 生存監視– Nagios 、 Mon 、 Sensu

• メトリクス取得–Munin 、 GrowthForecast 、 Cacti

• 統合監視– Zabbix

とにかく手軽

必要な機能が揃っている

ミドルウェアと生きる

インフラエンジニアの主戦場• 下の層は手を動かすことが減った– ハードウェアの仮想化– OS は RHEL/CentOS 、 Ubuntu に集約

• 最もエキサイティングな分野–新しいミドルウェアが毎年いくつも登場– 性質を見抜き、最適な場所に投入– ソフトウェア単位では数年で陳腐化

どうすればこの先生きのこれるか

どうすればこの先生きのこれるか

• 人は考えることに注力しよう！– 利用できることは利用しよう

• IaaS 、 PaaS 、 BaaS• AWS等クラウド事業者の提供するコンポーネント

– 自動化できることは自動化しよう• Puppet 、 Chef• Vagrant• 継続的デリバリー

– 抽象化できることは抽象化しよう• IaaS• Docker

どうすればこの先生きのこれるか

• ミドルウェアの「性質」をつかもう！– データベースとか分散 DB とか MQ とか• 得意とするデータの形式• 更新の方法・頻度、取得の方法・頻度• ボトルネックはどこか

–Web サーバとか AP サーバとか• キャッシュ• 接続の管理方法• SSL アクセラレーション

– 最適な場所に最適なものを！パズル！

どうすればこの先生きのこれるか

• コンピュータサイエンスを学ぼう！– 基礎を知っている人は強い–新しいものが出てもすぐに順応できる–むしろ余計なことを覚えずに済む

–経験に理詰めを加えることで最強に見える「推測するな、計測せよ」　　１．経験から仮説をたてる　　２．計測する　　３．結果をもとに理詰めで対策する

どうすればこの先生きのこれるか

• セキュリティの知識をつけよう–情報セキュリティと、暗号化技術–脆弱性のリスク分析ができる–私たちは、

　　何を　　何から　　どのように守りたいのか？

The Heartbleed Bug

CVE-2014-0160TLS 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

The Heartbleed Bug

CVE-2014-0160TLS 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

ちゃんと追

いかけられていますか？

どうすればこの先生きのこれるか

• セキュリティの知識をつけよう–情報セキュリティと、暗号化技術–脆弱性のリスク分析ができる–私たちは、セキュリティ技術を使って

　　何を　　何から　　どのように守りたいのか？

どうすればこの先生きのこれるか

• 新しい情報へのアンテナを張り続けよう–新しい脆弱性• 極めて緊急性の高い脆弱性にもすぐ対応できる• 読み解くためにはセキュリティの知識が必須• Heartbleedでも詳細解説出るには数日

–新しい技術、ソフトウェア• 「使ってみた」系記事• 「どう使ってみたい」系記事• 公式ドキュメント、 GitHub

!?

どうすればこの先生きのこれるか

• 新しい情報へのアンテナを張り続けよう– 新しい脆弱性

• 極めて緊急性の高い脆弱性にもすぐ対応できる• 読み解くためにはセキュリティの知識が必須• Heartbleedでも詳細解説出るには数日

– 新しい技術、ソフトウェア• 「使ってみた」系記事• 「どう使ってみたい」系記事• 公式ドキュメント、GitHub

– 急に流行が来ても、嗅覚が効く。

どうすればこの先生きのこれるか

• 情報交換をしよう–ブログを書こう• 突っ込まれる──だがそれが良い。• リファラー見てニヤニヤできる。

–技術の話ができる相手を見つけよう• Twitter 、 Facebook• エンジニア勉強会、セミナー、展示会

–懇親会も機会の一つ• ちょっとウザイぐらいでも絡んで行っちゃおう• Twitter とかでも絡めるようになれば勝ち

まとめ• 「ミドルウェア」ってなによ？– OS とアプリケーションの間のすべて

• Web3 層モデルで何考えればいいの？–Web+AP の中にデータを持たない– DB のデータを気合いで守る–推測するな、計測せよ

• ミドルウェアと付き合っていこう–積極的に勉強しよう、アンテナ張ろう、話し合おう！