目次
はじめに
こんにちは、クラウド事業部の山本です。
OCIではARMインスタンスが4コア/24GB RAMまで無料枠として利用可能です。
無料枠の中でもかなりのリソースを誇るこのARMインスタンスがどこまでのアクセス集中に耐えられるか試しにテストしてみました。
準備
今回の検証のざっくり要約です。
- 送信側と受信側でそれぞれインスタンスを用意
- 受信側インスタンスをARMインスタンス(4コア/24GB RAM)として起動
- 受信側にはNginx、送信側にはApacheBenchを導入し受信側に対して徐々にリクエスト数を増加させていく
それでは、準備を進めていきます。
インスタンス起動
まずは受信側のARMインスタンスを起動していきます。
※今回イメージに特にこだわりはないので、受信/送信どちらもデフォルトのOracle Linux 9を利用しています。
シェイプ変更画面で「Ampere」を選択します。
OCPU/メモリを無料枠の最大である4コア/24GBに設定します。
ちなみにリソースを指定するにはシェイプ名の横にある小さいプルダウンをクリックする必要があります。
(私は初めどこかわからず右往左往しました。。。)
その他パラメータは適当なものを指定し作成しておきます。
送信側も同様ですが、こちらも安価なシェイプを選択しておきます。
(本当はこちらも無料枠で立てたかったのですが、クォータ制限だったのでVM.Standard.E2.1を選択しました)
ミドルウェア導入
まずは受信側です。
Nginxを導入していきます。
sudo dnf install -y nginx sudo systemctl start nginx sudo systemctl enable nginx
念のため動いていることを確認します。
[opc@vm-reciever ~]$ systemctl status nginx
● nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: disabled)
Active: active (running) since Wed 2026-05-27 05:51:14 GMT; 2s ago
Process: 81162 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Process: 81163 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 81164 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
Main PID: 81165 (nginx)
Tasks: 5 (limit: 146308)
Memory: 4.5M (peak: 4.8M)
CPU: 31ms
CGroup: /system.slice/nginx.service
├─81165 "nginx: master process /usr/sbin/nginx"
├─81166 "nginx: worker process"
├─81167 "nginx: worker process"
├─81168 "nginx: worker process"
└─81169 "nginx: worker process"
May 27 05:51:14 vm-reciever systemd[1]: Starting The nginx HTTP and reverse proxy server...
May 27 05:51:14 vm-reciever nginx[81163]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
May 27 05:51:14 vm-reciever nginx[81163]: nginx: configuration file /etc/nginx/nginx.conf test is successful
May 27 05:51:14 vm-reciever systemd[1]: Started The nginx HTTP and reverse proxy server.
また、デフォルトではポートが閉じていることが多いのでファイアウォールを開放しておきます。
sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --reload
こちらも念のため確認しておきます。
[opc@vm-reciever ~]$ sudo firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: enp0s6 sources: services: dhcpv6-client http ssh ports: protocols: forward: yes masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
今回準備編では詳細を割愛していますが、もちろんOCI側のセキュリティリスト・NSGの設定も必須です。
受信側/送信側のインスタンスが通信できる状態にしておきます。
続いて送信側です。
ApacheBenchを導入していきます。
といってもApacheのツールをインストールするだけで完了です。
sudo dnf install -y httpd-tools
検証
いよいよ検証です。
検証手順はシンプルで、送信側からリクエストを送り、受信側でtopコマンドを使って確認していくという流れで行います。
リクエスト送信
一旦現状を確認しておきます。
CPU/メモリ共にほとんど使用されていない状態ですね。
top - 06:20:40 up 22:56, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 239 total, 1 running, 238 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.0 sy, 0.0 ni, 99.9 id, 0.0 wa, 0.1 hi, 0.0 si, 0.0 st MiB Mem : 22945.6 total, 19494.6 free, 914.2 used, 2865.9 buff/cache MiB Swap: 5120.0 total, 5120.0 free, 0.0 used. 22031.4 avail Mem
まずは小手調べで「同時アクセス50、合計5,000リクエスト」を投げてみます。
ab -c 50 -n 5000 http://10.0.0.124/
結果としては10%程度CPUが使用されていますが、まだまだ余裕な状態です。
top - 06:25:44 up 23:01, 1 user, load average: 0.06, 0.02, 0.00
Tasks: 242 total, 1 running, 241 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.1 us, 4.0 sy, 0.0 ni, 89.3 id, 0.0 wa, 0.3 hi, 3.2 si, 2.1 st
MiB Mem : 22945.6 total, 19479.9 free, 925.5 used, 2869.4 buff/cache
MiB Swap: 5120.0 total, 5120.0 free, 0.0 used. 22020.1 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
81166 nginx 20 0 15316 4168 2476 S 9.0 0.0 0:00.53 nginx
81167 nginx 20 0 15316 4164 2476 S 4.3 0.0 0:00.22 nginx
81169 nginx 20 0 15316 4164 2476 S 1.7 0.0 0:00.06 nginx
それでは次は一気に「同時アクセス200、合計50,000リクエスト」まで増やしてみます。
top - 06:34:53 up 23:10, 1 user, load average: 0.28, 0.06, 0.02
Tasks: 238 total, 1 running, 237 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.8 us, 15.6 sy, 0.0 ni, 58.7 id, 0.0 wa, 1.4 hi, 12.1 si, 9.4 st
MiB Mem : 22945.6 total, 19466.4 free, 927.9 used, 2880.5 buff/cache
MiB Swap: 5120.0 total, 5120.0 free, 0.0 used. 22017.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
81166 nginx 20 0 15448 4248 2476 S 29.2 0.0 0:04.03 nginx
81167 nginx 20 0 15316 4184 2476 S 20.3 0.0 0:02.60 nginx
81169 nginx 20 0 15316 4168 2476 S 8.6 0.0 0:01.02 nginx
81168 nginx 20 0 15316 4164 2476 S 1.3 0.0 0:00.15 nginx
かなり使用率が上がってきました。
それでもまだ余裕がありそうなので、さらに増やして「同時アクセス500、合計500,000リクエスト」で試してみます。
top - 06:41:08 up 23:16, 1 user, load average: 0.82, 0.39, 0.15
Tasks: 234 total, 1 running, 233 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.5 us, 11.9 sy, 0.0 ni, 55.3 id, 0.1 wa, 1.3 hi, 18.9 si, 9.9 st
MiB Mem : 22945.6 total, 19382.4 free, 938.6 used, 2953.9 buff/cache
MiB Swap: 5120.0 total, 5120.0 free, 0.0 used. 22007.1 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
81166 nginx 20 0 15544 4384 2476 S 32.2 0.0 0:41.39 nginx
81167 nginx 20 0 15316 4188 2476 S 15.3 0.0 0:19.13 nginx
81169 nginx 20 0 15316 4168 2476 S 5.3 0.0 0:06.46 nginx
81168 nginx 20 0 15316 4168 2476 S 1.3 0.0 0:01.24 nginx
意外にもそこまで負荷は変わらずまだまだ余裕はありそうな感じでした。
ここでOS側の上限に達する
いっそのこと数値を莫大に上げて限界を迎えるまで追い込もうと思った矢先、
先にOS側が上限に達してしまいます。
[opc@vm-sender ~]$ ab -c 2000 -n 1000000 http://10.0.0.124/ This is ApacheBench, Version 2.3 <$Revision: 1913912 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 10.0.0.124 (be patient) socket: Too many open files (24)
そのため同時アクセス数の上限を50,000まで解放します。
ulimit -n 50000
また、受信側もnginx.confを編集して上限を上げておきます。
(中略)
events {
worker_connections 50000;
}
(中略)
いざ再試行！と思い同時アクセス数を一気に10,000まで上げてみたのですが、結果はそこまで変わらずでした。
(その後解放した50,000まで上げてみましたが、同じような結果になりました。)
top - 05:19:37 up 5:21, 2 users, load average: 0.76, 0.27, 0.10
Tasks: 242 total, 2 running, 240 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8.9 us, 10.5 sy, 0.0 ni, 52.5 id, 0.0 wa, 1.2 hi, 18.8 si, 8.1 st
MiB Mem : 22945.6 total, 18728.0 free, 950.2 used, 3554.8 buff/cache
MiB Swap: 5120.0 total, 5120.0 free, 0.0 used. 21995.4 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16613 root 20 0 805760 77280 26168 S 37.7 0.3 0:01.57 ruby
2372 nginx 20 0 36492 25320 2464 S 13.9 0.1 5:14.03 nginx
2373 nginx 20 0 36464 25320 2464 S 9.6 0.1 5:41.40 nginx
2370 nginx 20 0 36392 25220 2464 S 8.9 0.1 5:37.58 nginx
2369 nginx 20 0 36456 25320 2464 S 8.3 0.1 5:08.13 nginx
打開策
ここで一つの疑念が思い浮かびます。
「送信側がボトルネックになっており、一定数以上のリクエストが上手く送信できていないのでは？」と。
急遽ARMインスタンスと同じリソースを指定したVM.Standard.E4.Flexインスタンスを新たに用意します。
起動してリクエストを送ってみると...？
ついにCPUが逼迫しましたね。
top - 02:22:02 up 2:23, 1 user, load average: 1.71, 0.46, 0.33
Tasks: 238 total, 5 running, 233 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.3 us, 38.5 sy, 0.0 ni, 0.3 id, 0.0 wa, 2.7 hi, 30.0 si, 23.1 st
MiB Mem : 22945.6 total, 18935.8 free, 868.6 used, 3427.5 buff/cache
MiB Swap: 5120.0 total, 5120.0 free, 0.0 used. 22077.0 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2370 nginx 20 0 36208 25056 2464 R 45.5 0.1 5:02.23 nginx
2373 nginx 20 0 36208 25012 2464 R 44.9 0.1 5:07.18 nginx
2372 nginx 20 0 36208 25024 2464 R 43.6 0.1 4:39.01 nginx
2369 nginx 20 0 36212 25060 2464 R 39.9 0.1 4:33.44 nginx
おまけ
リクエストを送った時の送信側のスタッツを見てみました。
＜シェイプ変更前＞
Concurrency Level: 5000
Time taken for tests: 162.118 seconds
Complete requests: 1000000
Failed requests: 616
(Connect: 0, Receive: 0, Length: 616, Exceptions: 0)
Non-2xx responses: 616
Total transferred: 4627356744 bytes
HTML transferred: 4392401712 bytes
Requests per second: 6168.36 [#/sec] (mean)
Time per request: 810.588 [ms] (mean)
Time per request: 0.162 [ms] (mean, across all concurrent requests)
Transfer rate: 27874.21 [Kbytes/sec] received
＜シェイプ変更後＞
Concurrency Level: 2000
Time taken for tests: 108.311 seconds
Complete requests: 1600000
Failed requests: 16
(Connect: 0, Receive: 0, Length: 16, Exceptions: 0)
Non-2xx responses: 16
Total transferred: 7407931344 bytes
HTML transferred: 7031932512 bytes
Requests per second: 14772.29 [#/sec] (mean)
Time per request: 135.389 [ms] (mean)
Time per request: 0.068 [ms] (mean, across all concurrent requests)
Transfer rate: 66792.07 [Kbytes/sec] received
上述の通り変更前/後でリクエストの秒間送信数が大きく変わっています。
変更前は一定のリクエスト数を超えるとどれだけ上げても秒間送信数が6,000前後から変わりませんでしたが、
リソース増強後は増加しているため今回少しハマったポイントはここだったのかなと思います。
(せっかく受信側を無料枠で立てたのに結果同等のリソースを有料で立てることになってしまいましたが泣)
まとめ
結論として無料枠のARMインスタンスでも秒間15,000リクエスト程までなら耐えられるかも？という結果になりました。
これが動的ホームページだったりするとまた話が変わってくるかと思いますので、
あくまで参考目安として捉えていただけると幸いです。
おわりに
私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。
また、一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
