Recommended
More Related Content
What's hot
What's hot (20)
Similar to 高負荷に耐えうるWeb application serverの作り方
Similar to 高負荷に耐えうるWeb application serverの作り方 (20)
高負荷に耐えうるWeb application serverの作り方
- 2. Y. I. GMO インターネット株式会社 次世代システム研究室 アシスタントマネージャー シニアアーキテクト Engineer歴 20年 好き DB / Elixir-lang 自己紹介 2
- 3. Goal 高負荷に耐えうる WebApplication の Architecture を設計する際に ・どこで対策するか ・どのように構築するか をご紹介します。 Programing codeではなくinfraよりの説明になりま す。高負荷対策は多数ありますが一例とおぼえてお いていただくことをGoalとしています。 3
- 4. section 0 対象とするWebApplicationの説明（前提） section 1 どういった案があるか説明（抽象的） section 2 設定の説明（具体的） pages 71. Agenda 4
- 6. あるスマートフォン向けゲームサーバーにて行った負荷対 策を元に説明します ・[OS] CentOS7 ・[WEBサーバー] NGINX ・[APIサーバー] NGINX + PHP-FPM ・[CACHE] Memcached, Redis ・[DB] MySQL(MariaDB) ゲームクライアントとJSON APIおよびHTMLや画像/動画 をやり取りする構成です 対象とするWebApplication 6
- 7. 全体構成図 7 LB API CACHE memcached DB WEB ・・・ master ・・ CACHE Redis slave s/m slave backup s/m slave backup s/m slave backup s/m slave backup UserDB01 UserDB02 LogDB02LogDB01 MasterDB01
- 8. 全体構成図 ~改善ポイント~ 8 LB API CACHE memcached DB WEB ・・・ master ・・ CACHE Redis slave s/m slave backup s/m slave backup s/m slave backup s/m slave backup UserDB01 UserDB02 LogDB02LogDB01 MasterDB01 サーバー 振り分け設定 Scaleout レプリケーション Table Partitioning 垂直分割 水平分割 CacheによるDB アクセス削減 Scaleout Replication Ranking
- 10. ◆ scaleup （1台の性能を上げる） 性能が高いサーバーハードウエアを利用して性能 を上げる ◆ scaleout（台数を増やす） サーバーを増やして合計の処理性能を上げる ◆ 他 programing codeの最適化 OS / Middleware のconfig最適化 基本 ~~ 10
- 14. 「Nginxのキャッシュ付きリバースプロキシーでキャッ シュしたContentsを返却する」 response内容をキャッシュしておいて返却します 都度requestを処理してresponse内容をつくるよりも キャッシュからレスポンスするので高速です ※本PJでは次で紹介するCDNを使うので Nginxでの キャッシュは行っていません WEBサーバー ~Contents Cached Reverse Proxy~ 14
- 15. 外部の有料サービスである CDN(Contents Delivery Network) を利用する ・CDNを簡単に説明すると、クライアントからのアクセスを変わり に受けてくれるキャッシュサービスです ・全世界に配信サーバーを持っていてクライアントから一番近い サーバーでContentsキャッシュをレスポンスしてくれます ・DDoS攻撃への対応も可能 ・Akamai、AWS CloudFront が有名 こちらは有料なだけあって非常に効果が高い おすすめ WEBサーバー ~CDN~ 15
- 19. ◆同じユーザー/sessionが同じAPIサーバーに振り 分けられるか保証されない =>どのサーバーに振り分けられても問題ない作りに することが大事 ・他 Sticky Sessionを使うとLoadBalancerがcookieを元に同一サー バーへ振り分けてくれますが、クラウドサービスによってSticky Session の Cookie Expire 時間が短いなど問題になることもある ので可能な限りどのAPIサーバーに振り分けられても問題がない ように設計したほうが良い API ~Scaleout/気をつける事~ 19
- 20. ◆Ephemeral port（自由に使える短命port） の枯 渇 Linuxはportを65535番まで持っていて、通信などで自由に使える portは一般的に 32768 ~ 61000 の 28232個のportを利用可能 です Ephemeral portが全て使われてしまうと使えるportがないために 新しい通信を行うことができなくなります =>同時通信数をあげる必要がある場合は kernelパラメータにて Ephemeral portを増やすことが可能です API ~Scaleout/気をつける事~ 20
- 21. ◆APIサーバーのScaleout最大数 は DBの同時接 続数が限界になる APIサーバーが多数のrequestを受けられてもDB同時接続数を超え た際にDB接続待ちが発生してしまう DBサーバーの限界を超えたAPIサーバー台数を用意しても無駄に なってしまう =>DBのスループットを上げることが大事 =>遅いQueryを投げてしまうとDBが詰まりやすくなるのでProgram で実行するQueryの最適化も大事 API ~scaleout/気をつける事~ 21
- 22. Cacheサーバー 22
- 28. DBサーバー 28
- 29. ◆DBサーバーを分ける（scaleout） ・Replication（read用DBを増やして負荷分散） ・Vertical Sharding（機能毎にDBを分割） ・Horizontal Sharding（データ毎にDBを分割） ◆データ保存領域を分ける ・table partitioning ◆設定 DB設定の最適化 OS設定の最適化 DB ~負荷対策案~ 29
- 32. ◆レプリケーション例 3レイヤーのレプリケーション構成 masterDB > slave & masterDB > slave DB ~Replication~ master slaveslave/m aster slave backup 32 Replication向きSlaveDBがMasterDB を兼ねることも可能
- 34. Programで接続先DBを使い分ける ・User系テーブルならばUserDBへ ・Log系テーブルならばLogDBへ ◆垂直分割例 機能毎にDBを分割 ・User系DB ・Log系DB DB ~Vertical sharding~ slave/m aster slave backup 34 User系DB slave/m aster slave backup Log系DB API PHP-FPM
- 36. ◆データ毎の水平分割例 [ルール] user_id の 偶数(even) / 奇数(odd) などで分ける DB ~Horizontal sharding~ slave/m aster slave backup 36 user_id even slave/m aster slave backup user_id odd API PHP-FPM Programで接続先DB を使い分ける
- 37. ◆本PJでの水平分割例 本PJではDB Serverを2セット、DB schemaを8分割しています [ルール] user_id % 8 で8分割（剰余算 mod） DB負荷が上がったら最大8台のDB Serverへ分割可能です ※mod 128にすれば128台へ分割可能ですが管理が大変なのでほどほどに... DB ~Horizontal sharding/本PJ~ slave/m aster slave backup 37 db 00,02,04,06 を保存 slave/m aster slave backup db 01,03,05,07 を保存 API PHP-FPM Programでルールに合わせて接続先 DBを使い分ける mod 0,2,4,6ならば server1mへ mod 1,3,5,7ならば server2mへ 00 02 04 06 00 02 04 06 01 03 05 07 01 03 05 07 [db server1m] [db server1s] [db server2s] [db server2m]
- 38. Table毎に保存するFileをわける １つのTableの保存領域をルールを決めて複数にわけることで参照 時に目的のデータを探す（Seek）時間が短くなる Table A 100,000,000(1 hundred million) records ↓ Table A[partition] 1,000,000(1 million) × 100[partition] =>ルールに沿った検索だと 1partitionのみ参照すれば良い！ MySQLではルールとしてPrimary Keyにpartition rule columnを含 める必要がある DB ~table partitioning~ 38
- 39. CREATE TABLE文 CREATE TABLE `log_training`( `id` bigint unsigned auto_increment NOT NULL COMMENT '管理用ID' ,`user_id` int unsigned NOT NULL COMMENT 'ユーザーID' ,`mst_training_id` int unsigned NOT NULL COMMENT '特訓ID' ,`type` int unsigned NOT NULL COMMENT '種別(0:消費、1:付与、2:売却)' ,`amount` int NOT NULL COMMENT '増減量' ,`count` int unsigned NOT NULL COMMENT '個数' ,`created` datetime NOT NULL COMMENT '登録日時' ,PRIMARY KEY(`id`, `user_id`) ,KEY log_training_idx1(`user_id`) ,KEY log_training_idx2(`mst_training_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='特訓ログ' PARTITION BY HASH(MOD(`user_id`, 100)) PARTITIONS 100; ※ user_idを100で割った余りでpartition100個を入れ分けている ※ 主キーにpartition ルールで使っているuser_idカラムを含めている DB ~table partitioning~ 39
- 40. ◆ Table partitioningのイメージ図 クエリのWHERE句にuser_idを指定して検索する と該当の領域のみSeekする [ルール] user_id % 100 ・mod 0 -> 00の領域へ保存 ・mod 1 -> 01の領域へ保存 ・mod 99-> 99の領域へ保存 Table log_training DB ~table partitioning~ 40 1つのTable 保存領域がわ かれている 00 X [Table log_training] 01 03 04 05 06 99 保存領域
- 41. DBは設定できるパラメータが多数あり、要件に合わせて設定を変更 する必要があります （具体的な設定は section 2 にて） DB ~設定~ 41
- 42. Linux Kernel パラメータの変更 ・Memory ・OpenできるFile Descripterを増やす ・起動できる Process 数を増やす ・Disk設定 ・Network設定 ・Ephemeral port を増やす などの設定を行います （具体的な設定は section 2 にて） Linux 設定 42
- 47. Nginx ~説明~ Nginxは http daemon であり Non blocking I/O と async I/O により大量のアクセスに対応することが 可能 URLによる L7 Load balancing が可能 LuaスクリプトやC言語で独自の判定処理を実装出 来て複雑な処理も可能 47
- 48. Nginx ~conf~ /etc/nginx.conf の重要パラメータ worker_processes nginxのプロセスをいくつ起動するか worker_connections worker１つあたりの最大接続数 multi_accept on requestを同時に受けられるようにする use epoll requestの状態変化をkernelに任せて次の処理を 行う(Linux システムコール) 48
- 49. WebサーバーでPHPを動作させるDaemon PHPのFastCGI実装の一つ FPM (FastCGI Process Manager) FastCGIとは requet毎に生成破棄されるCGIプロセスを保持するようにして高 速に再利用できるようにした仕組み php-fpm ~説明~ 49
- 50. 重要な設定 pm.max_children php-fmpの最大worker数, この値が一番大事！ server memoryが許すまで大きめの値を設定したい 下記コマンドで消費メモリを測定 ps aux | grep php-fpm | awk '{sum += $6} END {print sum}' pm.start_servers 起動時に作成するworker数 pm.min_spare_servers 維持する最小worker数 pm.process_idle_timeout workerを停止するまでのidle時間min_spare_servers数 php-fpm ~php-fpm.conf~ 50
- 53. Cache ~memcached~ /etc/sysconfig/memcached 重要なパラメータ MAXCONN = 65535 最大接続数, Ephemeral port以上に設定 CACHESIZE = 3000 (MB) 利用可能物理Memory以内で設定 53
- 55. 重要なパラメータ maxclients 50000 最大接続数 maxmemory 14gb 最大Memoryサイズ 多数のパラメータがあるが上記は最低限サーバーリソースに合 わせて設定する必要がある Cache ~Redis~ 55
- 56. ◆ Replication構成は可能な限り3台以上の構成にすることをおす すめします 1台余剰のSlaveDBがあると ・リアルタイムでDBを参照できる ・エンドユーザーに影響せずに重い集計クエリを実行できる ・DBへの書き込みを止めてBackupを取得できる ・MasterDBが壊れた際の予備にできる などが可能になります (1)masterDB（エンドユーザー向け） (2)slaveDB（エンドユーザー向け） (3)slaveDB（社内向け / KPI参照 / Backupを取得 / 故障時の代替サーバー） DB ~気をつける事 1/2~ 56
- 57. ◆ Backupは mysql dir毎コピーを取る方法がおすす め ・tarコマンド等で /var/lib/mysql 毎バックアップする ・/var/lib/mysql/master.infoファイルにreplication設定やbinlog positionが記入されているため、masterDBにbinlogファイルが残っ ていればバックアップから最新状態まで復旧可能 ※注意！ master.infoがあるとmysql起動時にreplicationを開始してしまうの でmaster.infoを移動しておくか確認すること (例)バックアップを元に別サーバーのmysqlを復旧するときなど起動 と同時にバックアップサーバー設定のreplicationを開始しては問題 がある状況など DB ~気をつける事 2/2~ 57
- 58. 本PJの要件において効果が高かったパラメータ ※システム要件によって効果的なパラメータは異なるためシステム毎に要検討 負荷テストにおいて設定した値 max_connections: 10000 connection数上限エラーが発生したためMemoryが許す範囲で高く持った -> connectionエラーが減った transaction-isolation: READ-COMMITTED lock待ちになることが多くあったため変更 ->lock待ちが減った ※本PJの要件的にこの分離レベルで問題がないため設定 innodb_buffer_pool_instances: 16 ->若干qpsが向上した DB ~my.cnf / 効果あり 1/2~ 58
- 59. innodb_lock_wait_timeout: 5 lock待ちが長すぎてconnection上限エラーが発生しやすかったので変更 ->5sec以上のlock waitは失敗として終了させて全体が詰まることを減少 innodb_io_capacity_max: 30000 innodb_io_capacity: 20000 Fusion ioMemory向け設定 ※io_capacityを100000など高い値にしたところ2回目以降の高負荷時にqpsが50%ほど 下がる減少が発生した innodb_buffer_pool_size: 64G conneciton毎に必要とするメモリなど他使用メモリを引いた残りのメモリの80%で設定 ->DB serverはswapを発生させてはならない innodb_flush_method: O_DIRECT osのpage cacheを使わずに直接writeする DB ~my.cnf / 効果あり 2/2~ 59
- 60. 本PJでのmy.cnf設定（Ansible template） character_set_server: utf8mb4 max_connections: 10000 max_connect_errors: 50 transaction-isolation: READ-COMMITTED # innodb innodb_buffer_pool_size: 64G innodb_buffer_pool_instances: 16 innodb_flush_method: O_DIRECT innodb_flush_log_at_trx_commit: 1 innodb_file_per_table: 1 innodb_data_file_path: ibdata1:10M:autoextend innodb_file_format: Barracuda open_files_limit: 163840 innodb_open_files: 128000 DB ~my.cnf 1/3~ 60
- 61. # Set .._log_file_size to 25 % of buffer pool size innodb_log_file_size: 2G innodb_log_buffer_size: 64M innodb_support_xa: 1 innodb_lock_wait_timeout: 5 # io threads 並列化可能な状況ならば max64 以内で設定 innodb_write_io_threads: 16 innodb_read_io_threads: 16 innodb_thread_concurrency: 0 # fusion-io/SSD innodb_io_capacity_max: 30000 innodb_io_capacity: 20000 # memory sort_buffer_size: 2M join_buffer_size: 2M read_buffer_size: 1M max_allowed_packet: 4M DB ~my.cnf 2/3~ 61
- 62. # replication server_id: "{{ ansible_all_ipv4_addresses[0].split('.')[3] }}" <-server ip 4octetを利用 log_slave_updates: ON # binlog log_bin: mysql-bin binlog_format: MIXED expire_logs_days: 90 max_binlog_size: 500MB DB ~my.cnf 3/3~ 62
- 64. Kernel設定の変更によりServer自体の処理性能 が大きくあがります DB Server や API Server など要件に合わせて設 定を調整することが大切です ※次ページから具体的な設定を紹介します Kernel設定 ~~ 64
- 65. 重要な Linux kernel設定 net.ipv4.ip_local_port_range=10000 65535 Ephemeral portを設定、上記だとdefault 28000のところを55000使えるようになる net.core.somaxconn=65535 TCP接続数 最大Port数に設定するのがおすすめ net.ipv4.tcp_fin_timeout=5 TCPセッションがFIN-WAIT2からTIME_WAITへ変化する時間 net.ipv4.tcp_tw_reuse=1 TIME_WAIT状態のportの再利用を行う（接続先IP/portが同じサーバーの場合に再 利用可能） =>上記設定で同時通信数の最大化やport枯渇対策が可能 Kernel設定 ~/etc/sysctl.conf 1/3~ 65
- 68. /etc/security/limits.conf にos user毎にopen可能なfile descripterや起動できる process数を設定 設定値をあげることで Too many open files エラーが発生しにくくな る (例) os user u の file descripterとprocess数の上限を変更 u soft nofile 65535 u hard nofile 65535 u soft nproc 1006500 u hard nproc 1006500 Kernel設定 ~limits.conf~ 68
- 70. tunedはcentos7から導入された選択されたプロファイルに従ってシ ステム設定を静的および動的にチューニングするデーモン tuned-admコマンドで設定を変更可能 tuned-adm profile pj 独自のtuned profileを作ることが可能 /usr/lib/tuned/pj/tuned.conf tuned [main] include= throughput-performance [vm] transparent_hugepages=never vm.swappiness=0 本PJでは throughput-performance profileを継承して transparent_hupageのキャンセル や可能なかぎりスワップしない設定を追加しています Kernel設定 ~tuned~ 70