高負荷に耐えうるWebApplication Serverの作り方
•Télécharger en tant que PPTX, PDF•
10 j'aime•4,141 vues
高負荷に耐えうる WebApplication の Architecture を設計する際に ・どこで対策するか ・どのように作るか をご紹介します。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 高負荷に耐えうるWebApplication Serverの作り方
Similaire à 高負荷に耐えうるWebApplication Serverの作り方 (20)
Plus de GMO-Z.com Vietnam Lab Center
Plus de GMO-Z.com Vietnam Lab Center (20)
Dernier
Dernier (14)
高負荷に耐えうるWebApplication Serverの作り方
- 2. Xin chào！ Toi ten la Ishiyama Yuta. GMO Internet inc. 次世代システム研究室 (Innovation and Technology System Office) アシスタントマネージャー(Asistant Manager) シニアアーキテクト(Senior Architect) 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. PJ code「C2」 スマートフォン向けゲームのサーバーにて行った負荷 対策を元に説明します ・[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 レプリケーション 垂直分割 水平分割 CacheによるDB アクセス削減 Scaleout Replication Ranking
- 10. ◆ scaleup （1台の性能を上げる） 性能が高いサーバーハードウエアを利用して性 能を上げる ◆ scaleout（台数を増やす） サーバーを増やして合計の処理性能を上げる ◆ 他 programing codeの最適化 OS / Middleware のconfig最適化 基本 ~~ 10
- 14. 「Nginxのキャッシュ付きリバースプロキシーで キャッシュしたContentsを返却する」 response内容をキャッシュしておいて返却します 都度requestを処理してresponse内容をつくるより もキャッシュからレスポンスするので高速です ※C2では次で紹介する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/ master slave backup 32 Replication向きSlaveDBがMasterDB を兼ねることも可能
- 34. Programで接続先DBを使い分ける ・User系テーブルならばUserDBへ ・Log系テーブルならばLogDBへ ◆垂直分割例 機能毎にDBを分割 ・User系DB ・Log系DB DB ~Vertical sharding~ slave/ master slave backup 34 User系DB slave/ master slave backup Log系DB API PHP-FPM
- 36. ◆データ毎の水平分割例 [ルール] user_id の 偶数(even) / 奇数(odd) などで分ける DB ~Horizontal sharding~ slave/ master slave backup 36 user_id even slave/ master slave backup user_id odd API PHP-FPM Programで接続先DB を使い分ける
- 37. ◆C2での水平分割例 C2ではDB Serverを2セット、DB schemaを8分割しています [ルール] user_id % 8 で8分割（剰余算 mod） DB負荷が上がったら最大8台のDB Serverへ分割可能です ※mod 128にすれば128台へ分割可能ですが管理が大変なのでほどほどに... DB ~Horizontal sharding/c2~ slave/ master slave backup 37 db 00,02,04,06 を保存 slave/ master 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のイメージ図 Table log_training DB ~table partitioning~ 40 1つのTable 保存領域がわか れている クエリのWHERE句にuser_idを指定して検索すると 該当の領域のみSeekする [ルール] user_id % 100 ・mod 0 -> 00の領域へ保存 ・mod 1 -> 01の領域へ保存 ・mod 99-> 99の領域へ保存 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ファ イルが残っていればバックアップから最新状態まで復旧可能 DB ~気をつける事 2/2~ 57
- 58. c2の要件において効果が高かったパラメータ ※システム要件によって効果的なパラメータは異なるためシステム毎に要検討 負荷テストにおいて設定した値 max_connections: 10000 connection数上限エラーが発生したためMemoryが許す範囲で高く持った -> connectionエラーが減った transaction-isolation: READ-COMMITTED lock待ちになることが多くあったため変更 ->lock待ちが減った ※C2の要件的にこの分離レベルで問題がないため設定 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する, innodbでは DB ~my.cnf / 効果あり 2/2~ 59
- 60. c2での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] }}" log_slave_updates: ON # binlog log_bin: mysql-bin binlog_format: MIXED expire_logs_days: 180 max_binlog_size: 500MB DB ~my.cnf 3/3~ 62
- 64. Kernel設定の変更によりServer自体の処理性能 が大きくあがります DB Server や API Server など要件に合わせて 設定を調整することが大切です ※次ページから具体的な設定を紹介します Kernel設定 ~~ 64
- 65. 重要な Linux kernel設定 net.core.somaxconn=65535 TCP接続数 最大Port数に設定するのがおすすめ net.ipv4.ip_local_port_range=10000 65535 Ephemeral portを設定、上記だとdefault 28000のところを55000使えるように なる 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 c2の file descripterとprocess数の上限を変更 c2 soft nofile 65535 c2 hard nofile 65535 c2 soft nproc 1006500 c2 hard nproc 1006500 Kernel設定 ~limits.conf~ 68
- 70. tunedはcentos7から導入された選択されたプロファイルに従っ てシステム設定を静的および動的にチューニングするデーモン tuned-admコマンドで設定を変更可能 tuned-adm profile c2 独自のtuned profileを作ることが可能 /usr/lib/tuned/c2/tuned.conf tuned [main] include= throughput-performance [vm] transparent_hugepages=never vm.swappiness=0 c2では throughput-performance profileを継承して transparent_hupageのキャンセル や可能なかぎりスワップしない設定を追加しています Kernel設定 ~tuned~ 70