Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
BP Study #16 Linuxシステムの物理制約と(web)システム監視のポイント
Search
Toshiaki Baba
December 14, 2008
Technology
0
5
BP Study #16 Linuxシステムの物理制約と(web)システム監視のポイント
(スライドのホストをSlideShareから引っ越し)
https://www.slideshare.net/toshiak_netmark/bp-study-16-presentation
Toshiaki Baba
December 14, 2008
Tweet
Share
More Decks by Toshiaki Baba
See All by Toshiaki Baba
SREsのためのSRE定着ガイド
netmarkjp
12
4.8k
SREこのへんで苦戦しがちじゃないですか?
netmarkjp
13
5.8k
技術書を活用してほしい!
netmarkjp
0
350
しつこくじわじわパフォーマンスチューニング
netmarkjp
1
890
現場がさき、 プラクティスがあと、 原則はだいじに
netmarkjp
0
620
ばばさんは、なぜ本を書くの?という話
netmarkjp
0
500
SRE≠インフラなんだけどもう誤解されちゃってる から、DevOps新実装として Site Production Engineering はいかがでしょう?
netmarkjp
2
1.3k
非ITの事業会社にSREと言わずにSREを持ち込んだ
netmarkjp
16
28k
変化の激しいWebの世界でコンスタントに局面局面で勝つ方法論「OODAループ」
netmarkjp
0
1.5k
Other Decks in Technology
See All in Technology
パフォーマンス最適化のベストプラクティス
databricksjapan
0
210
能動学習のいろは:書籍「Human-in-the-Loop機械学習」3〜5章
hiroyoshiito
0
310
CloudflareとHonoを使って飲食店のレビューができるLINEアプリを作った
shinaps
1
510
QA Engineer Life @ LINE
line_developers_tw
PRO
0
150
使われないものを作るな!出口から作るデータ分析基盤 / Data Platform Development Starting from the User Needs
amaotone
16
4.8k
多言語化対応における TypeScript の型定義を通して開発のしやすさについて考えた / TSKaigi TypeScript Multilingualization
nabeliwo
2
390
Taking Flight with Tailwind CSS
opdavies
0
4.3k
生成AI活用推進の為にやったこと/やらなかったこと
ktc_wada
0
210
Google Cloudを組織(企業)で運用する時のベストプラクティス × 健康の環境分離戦略 #まるクラ勉強会
yasumuusan
0
190
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
1.7k
The depthes of profiling Ruby - RubyKaigi 2024
osyoyu
0
180
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
12
7.9k
Featured
See All Featured
Optimizing for Happiness
mojombo
371
69k
Facilitating Awesome Meetings
lara
43
5.6k
Writing Fast Ruby
sferik
622
60k
Building Flexible Design Systems
yeseniaperezcruz
320
37k
Producing Creativity
orderedlist
PRO
338
39k
Mobile First: as difficult as doing things right
swwweet
217
8.6k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
67
14k
A Modern Web Designer's Workflow
chriscoyier
689
190k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
Become a Pro
speakerdeck
PRO
13
4.6k
Building Better People: How to give real-time feedback that sticks.
wjessup
356
18k
Building a Scalable Design System with Sketch
lauravandoore
457
32k
Transcript
1 Linuxシステムの物理制約と (web)システム監視のポイント 馬場 俊彰
[email protected]
http://netmark.jp from heartbeats (http://heartbeats.jp)
2 誰? 株式会社ハートビーツのCTOです たまにJPUGのお手伝いもしています MSP(Management Service Provider)してます 24時間有人監視サービス フルマネージドサービス(ハウジング、ホスティング) 今:サーバエンジニア+ネットワークエンジニア
前職:JavaでWebシステム開発 前々職:サーバエンジニア+ネットワークエンジニア OS(主にLinux(CentOS))、ネットワーク機器、 ミドルウェア(ApacheとかRDBMSとか)の
3 お仕事のご紹介 システムの運用開始後に プロジェクトに参画することが多いです でも「いまさらどうしようもナイよ。。。」ということ もしばし 設計段階で考慮しておいてもらえれば… 設計段階で声をかけてもらえれば… と思うこともしばし 要件定義
設計 開発 テスト 移行 運用
4 今日のお題 Linuxシステムの物理制約 Linuxシステムを運用していく上で問題になるポイント・ 問題になったことがあるポイントをご紹介します 設計段階で活かしてもらえれば… (web)システム監視のポイント 我々が、普段何を気にしているかをご紹介します 監視設計に活かしてもらえれば…
5 今日はLAMPシステムを例にします こんな感じの、web+db 1Uサーバ2台の構成を想定します スモールスタート。って感じです ほんとにスモールスタートだと1台構成ですが、説明の 都合上2台にします VPSもいいんですが、それなり性能でハードウェアを使 webサーバ Apache
dbサーバ MySQL PHP + フレームワークなどなど インターネット
6 制約ポイントその1 ポイント:ネットワークI/Oするところ ネットワーク帯域 同時接続数 グローバルIPアドレス webサーバ Apache dbサーバ MySQL
PHP + フレームワークなどなど インターネット このあたり
7 制約ポイントその1 ネットワークI/Oするところ データの出入り口 ここが詰まるとどうしようもない コストをかけないでも段階的な解消はある程度できる(= 時間稼ぎはできる)けど、根本解決は厳しいことが多 いです 「物理的に無理です」
8 制約ポイントその1 ネットワーク帯域(1/2) Q.インターネット回線はどのくらい使えるのかな? A.回線業者によって違います 100Mbps回線なら、だいたい100Mbpsまで出ます ※あまり帯域使いすぎると別料金になることがあるの でご注意ください Q.回線がいっぱいいっぱいになるとどうなるの? A.同時接続数が異常に増えます
よくあるパターン:
9 制約ポイントその1 ネットワーク帯域(2/2) Q.回線がいっぱいいっぱいになったらどうしよう? A.中身を減らしましょう 画像データの容量削減 データ圧縮(mod_deflateなど) キャッシュを活用(特に動的サイト) 線を太くする もう1回線引いてみる
いっそ外に出す⇒CDN(値は張ります)
10 制約ポイントその1 同時接続数(1/3) Q.1台でどのくらい同時に接続を受け付けられます か? A.netstatコマンドのstateを見て、TIME_WAITが10000個 に差し掛かると実用上厳しくなってきます (20~30万円クラスのIAサーバの事例) このくらいの数になると、netstatコマンドの出力が終わ りません。。
11 制約ポイントその1 同時接続数(2/3) Q.同時接続が増えてきたらどうしよう? A.チューニングしましょう Linuxのカーネルパラメーターを変更して、ネットワーク ソケットの再利用をはやめます このあたりの話になると途端に日本語の資料が少なくな ります Apacheやプログラムのチューニングも並行してやりまし
ょう 日本語の資料も多いのでがんばりましょう
12 制約ポイントその1 同時接続数(3/3) Q.同時接続が増えてきたらどうしよう?(つづき) あまり同時接続数が増えると、ファイアウォール・ロー ドバランサーなどのネットワーク機器がボトルネック になります いい製品は初期費用がとてもとても高いです Linuxでなんとかする方法もあります ファイアウォール⇒iptables
ロードバランサー⇒LVS(L4) ※製品を買ったほうが幸せになることもありますよ
13 制約ポイントその1 グローバルIPアドレス Q.やっぱりIPv6ですか? A.そういう話ではありません グローバルIPアドレスの割り当てを後から増やすのは大 変なんです!(ネットワーク割り当てなので) 無停止・設定変更なしだと大変。無理な場合も多々あり 停止・設定変更アリであれば大丈夫 1本の上流回線あたりのIPアドレス数は限りがあるので、
みんなが拡縮→移転を繰り返すと。。。。 ⇒ラック内・ラック間のLANケーブルがスパゲッテイに なります。テプラやファイバタグを駆使して回避して
14 制約ポイントその2 ポイント:Apache 同時起動プロセスを増やす ハードウェアリソースをうまく使う メモリ、CPU、ディスク webサーバ Apache dbサーバ MySQL
PHP + フレームワークなどなど インターネット このあたり
15 制約ポイントその2 Apache PHPだとprefork(プロセスモデル)で実行することに 世間に事例も情報も豊富です そしてなぜか事欠かない失敗事例
16 制約ポイントその2 同時起動プロセスを増やす Q.どれだけ同時に起動できますか? A.がんばって増やしてみましょう システムリソース制限を回避 ユーザあたりのファイルディスクリプタの割り当てを増 やす ファイルオープン、Socketオープン、標準入力、標準出力、標準 エラー出力などで個別に消費します
Too many open files を回避します ユーザあたりの起動プロセス数を増やす 最近は無制限になってたりしますが念のため
17 制約ポイントその2 ハードウェアリソースをうまく使う(1/3) メモリをうまく使う 安くなったとはいえ、いっぱい載せると高いです PHPである以上、preforkでの起動になるので個々のプロセ スのサイズが並列数に直結します プロセスあたりのメモリ使用量を減らすのがポイント Apacheのロードモジュールの数を減らしてある程度対応 できます
フレームワークを使ってたりすると、ロードするクラス の数が多くなりがちみたいですね ⇒個々のプロセスサイズが大きくなりがち
18 制約ポイントその2 ハードウェアリソースをうまく使う(2/3) CPUをうまく使う コンパイルキャッシュ(APCなどのアクセラレータ)を使う OpenX(オープンソースの広告配信ソフト)では絶大な効果があり ました ロードアベレージ60→0.6 無駄なディスクI/Oをしない ご存じの方も多いと思いますが、ディスクI/Oって重いんです
ディスクI/Oが重いので、アクセスが多いサイトでは画像のアク セスログはとらないようにします ちなみに、LoadAverage=CPU(コア)数だったら過負荷では ないです
19 制約ポイントその2 ハードウェアリソースをうまく使う(3/3) ディスクをうまく使う 1ファイルのサイズには制限があります (32bit Linuxではだいたい2GB) ログはローテーションしてくださいね daily +
sizeのローテーションが嬉しいです 1ディレクトリのファイル数はほどほどにしてくださいね オペレーション上、3桁くらいまでにしてもらえると嬉しいです
20 制約ポイントその3 ポイント:MySQL ハードウェアリソースをうまく使う メモリ、CPU、ディスク webサーバ Apache dbサーバ MySQL PHP
+ フレームワークなどなど インターネット このあたり
21 制約ポイントその3 MySQL SQLの最適化をしてください! インフラチューニングでは限界があります 基本的にスケールアウトする方向になります、スケール アウトできる設計にしておいてくださいね 更新トランザクションと参照トランザクションの分離、 データソースも分離 遅延レプリケーションを考慮に入れた画面遷移、コーデ
22 制約ポイントその3 も ハードウェアリソースをうまく使う(1/2) メモリもディスクもうまく使う 参照が多いテーブルはできるだけオンメモリで動作する ようにしましょう 32bit Linuxではプロセスサイズの上限が小さいので、足りなくな りそうであれば64bit
Linuxを使いましょう 更新が多いのであれば、対象テーブルの物理データファ イルサイズは小さく保つのがポイントです MySQLは追記型ではないですが、データファイルが大きいと中身 スカスカでもinsertが重くなります 中身がスカスカになったらOPTIMIZE TABLEで縮小できます 1テーブル=1ファイルなMyISAMだと、32bit Linuxでは1フ
23 制約ポイントその3 も ハードウェアリソースをうまく使う(2/2) CPUもうまく使う サブクエリや、JOINの時に一時テーブルがメモリに収ま らないサイズだとディスクを利用します。ディスクI/O は重いので(以下略 一時テーブルのサイズは設定で変更できます 単位時間の処理数を増やすためにコネクトを高速化しま
しょう localhostへのTCP接続は、UNIXソケットより7.5%遅い 別サーバへのTCP接続は、localhostへのTCP接続より8~ 11%遅い(100Mイーサの場合)
24 システムを監視する 一般ユーザ視点でのチェック ビジネス視点でのチェック 障害を素早く検知(して、対応)←会社のお仕事 webサーバ Apache dbサーバ MySQL PHP
+ フレームワークなどなど インターネット
25 システムを監視する ちょっとしたコツ インターネット越しの監視は、結果のブレが大きいです 何度かのリトライは折り込み済み。 2回リトライが一般的? 監視ポイントの最適化が、システム安定化のカギです
26 システムを監視する 一般ユーザ視点でのチェック サイト表示、メールなどの各種サービスの応答速度を監 視します 例えば、サイトのトップページの応答が 3秒以内 ⇒OK 3~5秒 ⇒Warning
5秒~ ⇒Critical 文字列検知なんかもやってます 他にも、リソース監視もやってます LoadAverage、総プロセス数、ログインユーザ数、ゾンビ プロセス数、プロセス有無・・・
27 システムを監視する ビジネス視点でのチェック システムの稼働状況を、実績データを元に判定します 現在のログインユーザ数、直近の売上、メール配信数な どを元に、システムの稼働状況を判定します システム個別の判定基準になるので、チェックプラグイ ンは全て自作です
28 システムを監視する 障害を素早く検知(して、対応) ハートビーツの事務所では、24時間誰かが働いています アラートが発生したら「人が」すぐに対応します 「最近リトライが多いな~」など、障害の予兆を素早く 察知することで、大火事を予防します 「継続は力なり」ということで、何よりも続けることが 大事です
29 ご静聴ありがとうございました 馬場 俊彰
[email protected]
http://netmark.jp from heartbeats (http://heartbeats.jp)