サーバー設定のお話

2014/12/6 Kazunori Inaba
2014.12.6
TechmixHokkaido 2014
サーバー設定のお話
稲葉一紀＠札幌
1

稲葉一紀(KazunoriInaba)
サーバーインフラ専門のフリーランスエンジニア＠札幌
屋号：稲葉サーバーデザイン
http://inaba-serverdesign.jp/
おもにアプリ開発企業・エンジニア向けに
セキュリティ・可用性・性能・拡張性を考慮した
ちょっと気の利いた
サーバーインフラ構成設計・設定・や既存システムの性能改善調査・支援
を行います。
2
自己紹介(1)

自己紹介(2)
IaaSクラウドの比較調査など
•IaaSクラウド比較'14
http://www.slideshare.net/kazunoriinaba/20140411-iaascloud
•NAVERまとめ【クラウドサーバーサービス(IaaS)比較まとめ】
http://matome.naver.jp/odai/2141128309524837601
3

•札幌ライブ情報公開中
http://seesaawiki.jp/w/sapporo_rock_live/
今夜のライブの一部
4
自己紹介(3)

はじめに
Linuxサーバーについて、セキュリティやチューニングの基本的な考え方と、
ふつうにやっておくべき設定についてお話します。
※攻撃から完璧に防御する方法、サーバー性能を限界まで引き出す、といった話では
ありません。
※LAMPで1台から数台のWebサーバーを対象としますが、基本的な考え方はこれ
以外でも同じだと思います。
スライドはのちほどアップします。
http://www.slideshare.net/kazunoriinaba/
5

セキュリティ–基本的なポリシー
•基本的な設定を確実に行い、不正アクセスされる確率をできるだけ減らす。
•運用中
•ログを確認する。
•脆弱性の情報収集と迅速な対処を行う。
6

セキュリティ–参考文献
（いきなりですが時間がないので）以下などを参照してください。
•1時間でざっくり教えるサーバ運営超入門（インフィニットループさん）
http://www.slideshare.net/infinite_loop/1-10128499
→基本的な考え方などがすごくわかりやすい。
•Qiitaそこそこセキュアなlinuxサーバーを作る
http://qiita.com/cocu/items/e7c305ccffb6841d109c
→具体的な設定手順。
7

セキュリティ– クラウドとVPSの違い（一般的には）
• VPS
• 基本的にサーバーIPアドレス向けのパケットがすべてサーバーに届く。
• 不正なアクセスはiptablesでブロックできるが、処理負荷が大きくなる可能性がある。
• クラウド
• サーバーの上位でファイアウォールポリシーを設定でき、許可していないパケットはサーバー
に届く前にブロックされる。
※サービスによっては上位にIPSがあり、悪質すぎるアクセスを自動的にブロックする。
8
×
×

セキュリティ–ログ管理・監視
•何かあったときの調査のため、システムログ、アプリケーションログ、アクセスログは、一定期間保存を（期間の長さは組織/個人でポリシーを決める）。
•ディスクあふれに注意。
•サーバー上での保存期間を短くする工夫。
•fluentdでAmazonS3等に転送。
•Papertrailなどのログ集約サービスに転送。
•ログのチェック。
•目視は大変。
•特定の文字列が出現したら自動アラート通知するよう設定。
•ログ監視ツールSwatchの導入。
•ログ集約サービスPapertrailの機能。
9

セキュリティ–その他ピックアップ
•iptables
•上位にファイアウォールがあっても、併用して使ったほうがよいと思う。多段階防御。
•FTP
•SCP/SFTPか、せめてFTPSに。関係者のみであれば、証明書はオレオレでもよい。
•コントロールポートをTCP/21から変更すると少し安全性が増す。
•データ通信ポートの範囲を限定すると、ファイアウォールで許可するポートを絞れる。
•phpMyAdmin
•アクセス元IPアドレスやBASIC/Digest認証などで可能な限りのアクセス制限を。
•HTTPS必須で。お問い合わせフォームだけHTTPSにしてもphpMyAdminがHTTPだと、（暗号化して保存していない限り）データが平文で流れて意味がないのでは。
10

チューニング–基本的な考え方
•極力ディスクアクセスを減らす。
•メモリ使用量合計でサーバーの搭載メモリを超えないようにする。
•スワップを使うと圧倒的に遅い！
→ここではおもにメモリまわりのチューニングについてお話します。
11

チューニング–メモリ使用状況の確認
・freeコマンドがわかりやすい
$free-m
totalusedfreesharedbufferscached
Mem:996902930184572
-/+buffers/cache:145850
Swap:204752042
（参考）
Linuxのメモリー管理(メモリ－が足りない？,メモリーリークの検出/防止)
http://www.math.kobe-u.ac.jp/~kodama/tips-free-memory.html
「Linux(っていうかUNIXかな？)では,各プロセスにメモリを割り振った残りを
バッファ(buffer)とキャッシュ(cache)に利用して,ディスク入出力の負荷を減らしている。」
プロセスの実質的な
メモリ使用量合計 145MB
実質的な
メモリの空き 850MB
12

チューニング–ソフトウェアへのメモリ配分(1)
サーバーの各ソフトウェアへの最大使用メモリ配分を検討する。
•Web+DBサーバー1台の場合の配分例
Apache (+ mod_php)
40%
MySQL
40%
その他
20%
Apache/
Nginx
Proxy
5%
MySQL
40%
その他
20%
Tomcat/
Passenger/
PHP-FPM, etc.
35%
13
Apache (+ mod_php)
30%
MySQL
30%
その他
20%
Batch
20%

チューニング–ソフトウェアへのメモリ配分(2)
•Webサーバー1台＋DBサーバー1台の場合の配分例
Webサーバー
DBサーバー
Apache (+ mod_php)
80%
その他
20%
MySQL
80%
その他
20%
Apache/
Nginx
Proxy
10%
その他
20%
Tomcat/
Passenger/
PHP-FPM, etc.
70%
14

チューニング–Apache(1)
•Apacheの最大メモリ使用量
=1プロセスあたりのメモリ使用量x最大接続数(MaxClients)
→最大接続数を大きくし過ぎないよう注意！
•「1プロセスあたりのメモリ使用量」のおおよその値は、psコマンドの「RSS」、 topコマンドの「RES」で確認できる。(KB単位）
$psaux
USERPID%CPU%MEMVSZRSSTTYSTATSTARTTIMECOMMAND
…
apache116670.01.944939637536?SNov300:52/usr/sbin/httpd
15

ただし、、、
psコマンドの「RSS」の値は、親プロセスと共有しているメモリ領域分も含んでいる。
→プロセスが実際使用しているメモリは「RSS」の値より小さい。
WordPressを使用した場合で70-80%など。
（参考）
LinuxのプロセスがCopyonWriteで共有しているメモリのサイズを調べる
http://d.hatena.ne.jp/naoya/20080212/1202830671
↑共有しているメモリ領域分を調べるPerlスクリプトがある。
16

•同時接続数（ざっくり計算）
=1時間あたりの可能アクセス数
x(ページの表示にかかる秒数+KeepAliveTimeoutの秒数）/3600
1時間あたりのPVを3000,ページ表示に5秒,KeepAliveTimeoutを3秒とすると、
同時接続数=3000x(5+3)/3600=6.66
※でも、ブラウザは1アクセスで複数セッションを使うので、
最大接続数(MaxClients)はその5倍とか。
17

WordPressを使用したWebサイトの場合、、、
•Apache1プロセスのメモリ使用量が大きい
→preforkMPMの場合、同時接続が増えるとメモリ使用量が激増する。
Apache+mod_php
30MB
…
30MB x 30プロセス= 900MB
Apache+mod_php30MB
Apache+mod_php30MB
18

WordPressを使用したWebサイトの場合、、、
•Nginx+PHP-FPM(FastCGI)にすると、軽量化できる（極端な例）。
NginxMaster+Worker
2MB
2MB + 50MB x 5 = 252MB
PHP-FPM
50MB
PHP-FPM
50MB
PHP-FPM
50MB
…
Reverse Proxy
※静的ファイルへのリクエストはNginxが処理するよう設定する。
※.htaccessが使えないことに注意。
※Apache + mod_fcgi+ PHP-FPMも可。
19

チューニング–MySQL(1)
•MySQLの最大メモリ使用量
=max_connections*
(sort_buffer_size
＋join_buffer_size
＋read_buffer_size
＋read_rnd_buffer_size
＋net_buffer_length)
＋key_buffer_size
＋query_cache_size
＋innodb_buffer_pool_size
＋innodb_additional_mem_pool_size
＋innodb_log_buffer_size
thread buffers
global buffers
20

チューニング–MySQL(2)
一番大事なパラメーターは、、、
•InnoDBの場合、innodb_buffer_pool_size（デフォルト8MB）
InnoDBのデータやインデックスをキャッシュするバッファサイズ。
これを増やしたら、innodb_log_file_sizeも大きくすること。
•MyISAMの場合、key_buffer_size（デフォルト8MB）
MyISAMのインデックスをキャッシュするバッファサイズ。
↑これらにドカンと割り当てよう！
できれば、インデックスの合計サイズ以上を。
デフォルト値のままでは、サーバーに16GBとか32GBとかどんなにメモリを搭載しても、ディスクアクセスが頻繁に発生してパフォーマンスが出ません！
※MySQLTunerで診断して推奨設定を確認するという方法もある。
※AWSRDSなど、クラウドのRDBサービスは、あらかじめパラメーターがチューニングされている。
21

チューニング–キャッシュ、インデックス
•キャッシュ
•memcached,RedisでDBへのリクエスト結果をキャッシュ。
•DBインデックスを適切に設定する。
22

チューニング–CPU数
•通常のWebサイトであれば、そんなにCPUは使わないはず。
•メモリ4GB→CPU1つ
•メモリ8GB→CPU2つ（Apache＋アプリケーションで1つ、MySQLで1つ、など。）
•特殊な演算処理や、ログ解析処理などを頻繁に行う場合は、その分CPU数を増やす。クラウドであれば、クロックの高いCPUを選ぶ。
•MySQLの同時接続数が多い場合は、CPU数を増やすと性能がよくなる。
23

チューニング-サイジング(1)
サーバーの要求スペックを考える場合。
•Webの同時接続数からApache（＋アプリケーションサーバー、FastCGIなど）の最大メモリ使用量を計算。
•DBのインデックスサイズやデータサイズ、同時接続数から最大メモリ使用量を計算。
•これらを合計して、サーバーに必要なメモリ使用量を計算。
↑事前の想定は難しい。。。
→柔軟にサーバースペックを変更できるクラウドサーバーを利用すると便利。
Apache (+ mod_php)
1.5GB
MySQL
1.5GB
その他
1GB
24

チューニング-サイジング(2)
•クラウドサーバーを利用する場合
○スモールスタート
CPUx1、メモリ2GBなど低いスペックで運用開始。
→リソース不足となったときスペックを上げる。
予期せぬアクセス急増でアクセス不能が生じる可能性がある。
◎ラージスタート
CPUx4コア、メモリ8GBなど高いスペックで運用開始。
→リソースが余っているようであればスペックを下げる。
25

チューニング–リソース使用状況の見える化(1)
•監視ツールで、CPU、メモリ、ディスク使用状況を見える化。
•Zabbix,MRTG,Munin,Cactiなどの監視ツールを導入。
•NewRelic,Mackerelなどのクラウド監視サービス(SaaS)を利用という手も。
•監視サーバー不要。アカウントを作って、サーバーにエージェントをyuminstall(apt-getinstall)するだけなので簡単。
•サーバーダウン、メモリ・ディスクの空き不足などにアラート通知できる。
•無料利用の場合はデータ保存期間が1日、1週間、1ヶ月など少ないことに注意。
26

New Relic
Overview
27

•Webアクセス解析ツールでネットワーク転送量、クローラーによるアクセスなどを見える化。
•AWStats,Webalizerなどを導入。
•GoogleAnalyticsのようなマーケティングツールとは別の、インフラ的視点でWebアクセス状況を把握できる。
•ネットワーク転送量課金のあるAWS等クラウド移行時の見積もりの目安となる。
28

（個人的な意見）OS、ソフトウェアの選択
•「その選択で、Webサイト/システムの運用を自分（たち）がずっと続けられるかどうか。」という視点でも考えるとよいのでは。
→責任をもってずっと続けられる
お好きなものを。
→ずっと続けられない（かも）
できるだけ、ユーザーが多く情報収集しやすい、スタンダードなものを。
ex.CentOS/Ubuntu,Apache/Nginx,MySQL/PostgreSQLなど。
29

おわりに-サーバーの設定、運用について
•セキュリティ、チューニングの基本的な考え方は（あまり）変わらない。
•好きでやれればいいけど、覚えることも多く、設定はけっこう大変。運用はもっと大変。
•「このサーバー、機密情報保存しないから」と適当な設定のままでは、攻撃元として加担してしまうことも。
•最低限のチューニングもしないと、サーバースペックを無駄に大きくして余計なお金がかかることも。
•面倒な人は、レンタルサーバー、マネージドVPS/クラウド、PaaS（Herokuなど）の利用を。もしくは信頼のおける専門家に依頼を。
•やるからには責任をもって監視、対応を。
•なぜそう設定したのか、ドキュメントに残す。
30

サーバー設定のお話

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to サーバー設定のお話

Similar to サーバー設定のお話 (20)

Recently uploaded

Recently uploaded (9)

サーバー設定のお話