「さくらのクラウドシェル」でWebサーバを起動する(ngrok編)
さくらインターネットから新しいサービス、「さくらのクラウドシェル」がリリースされました。 ブラウザからワンクリックで利用できるオンラインのシェル環境が起動できます。無料で使えます!!
こちら無料で試すボタンを押すと、次のモーダルが現れます。
ここで「会員IDで利用する」を選んだ場合、アウトバウンド向けの各ポート(22/53/80/443/1024-65535)の通信が利用できます。会員IDでログインしない場合は通信ができない環境が起動します。
ボタンを押すとすぐにシェルが立ち上がります。
フォントや文字色、背景画像が選べたりします。
シェルとしてはZSHが起動し、Go、Python、Ruby、Node.js などの開発言語のほかに、Vim、Emacs、tmux、Git、Ansible、Terraform、さくらのクラウドをコマンドラインから操作できる usacloud があらかじめ導入されています。
さくらのクラウドシェルでWebサーバを起動する
さくらのクラウドシェルは外から通信を受けることはできないので、ちょっとしたツールを試したりすることはできますが、Webサーバなどサーバとして利用することは通常できません。 そこで、Ngrokというトンネルサービスを使用して、Webサーバを起動してみます。
このコードではGo言語とNgrokのライブラリを使っています。
クラウドシェルを起動後、
sakura@cloud-shell% mkdir server sakura@cloud-shell% cd server sakura@cloud-shell% curl -LO https://gist.githubusercontent.com/kazeburo/795c8602e26aca66301e0142bcc024ea/raw/b9b22dbb4b23d38d37e59dadceeec418d69ed499/main.go sakura@cloud-shell% go mod init server sakura@cloud-shell% go mod tidy sakura@cloud-shell% go run main.go
でサーバが起動します。
表示されたURLがクリッカブルになっている(便利!)なのでクリックして動作確認ができます。
さくらのクラウドシェルでは20分操作しないと自動終了されるので、Webサーバも20分で終了します。はい。
dnsdist のパフォーマンスを引き出すネットワーク設定
YAPC::Kyoto 2023、JANOG51 MeetingではDNSへの水責めの攻撃とその対策について話をさせていただきました。その中で DNS攻撃をフィルタリングするために利用している dnsdist についてチューニングにより大きくパフォーマンス向上できることがわかってきたので紹介します。
YAPCの記事 kazeburo.hatenablog.com
JANOG51 Meetingについての記事 knowledge.sakura.ad.jp
Linuxのネットワークパラメータのチューニング
Linuxのチューニングでよくある設定ですが、sysctl.conf で以下のカーネルパラメータをチューニングをします。
net.core.somaxconn = 65535 net.core.netdev_max_backlog = 16384 net.core.rmem_max = 134217728 net.core.wmem_max = 134217728
ここでは rmem_max
、wmem_max
だけを設定しています。 net.core.rmem_default
、 net.core.wmem_default
については後述します。
dnsdistのチューニング
listenするスレッド数を増やす
dnsdistでは addLocal
を増やすことでlistenerスレッドの数を増やせます。
addLocal("0.0.0.0:53", {reusePort=true}) addLocal("0.0.0.0:53", {reusePort=true}) addLocal("0.0.0.0:53", {reusePort=true}) addLocal("0.0.0.0:53", {reusePort=true})
この際に reusePort
を有効にするとそれぞれのスレッドにListen Queueが分散されるので高速化が見込めます。
また、CPU affinityを固定するのも良いでしょう
addLocal("0.0.0.0:53", {reusePort=true,cpus={0}}) addLocal("0.0.0.0:53", {reusePort=true,cpus={1}}) addLocal("0.0.0.0:53", {reusePort=true,cpus={2}}) addLocal("0.0.0.0:53", {reusePort=true,cpus={3}})
さらにTCPの接続が多い場合、キューのサイズを増やしておくと良いかもしれません
addLocal("0.0.0.0:53", {reusePort=true,cpus={0},tcpListenQueueSize=4096}) addLocal("0.0.0.0:53", {reusePort=true,cpus={1},tcpListenQueueSize=4096}) addLocal("0.0.0.0:53", {reusePort=true,cpus={2},tcpListenQueueSize=4096}) addLocal("0.0.0.0:53", {reusePort=true,cpus={3},tcpListenQueueSize=4096})
UDPのバッファサイズの調整
UDPの読み書きのバッファのサイズを大きくします。デフォルトはカーネルパラメータの net.core.rmem_default
、net.core.wmem_default
になります。なのでsysctlで設定することもできます。
setUDPSocketBufferSizes(8388608,8388608)
カーネルパラメータの net.core.rmem_max
、net.core.wmem_max
が設定できる最大値となります。
複数のUDPによるクエリを1度のシステムコールで読み込む
recvmmsg(2)
を使うことで1度のシステムコールで複数のUDPによるクエリを読み込むことができます。 setUDPMultipleMessagesVectorSize
はその最大個数を指定します。
setUDPMultipleMessagesVectorSize(100)
デフォルトは1で、通常の recvmsg(2)
を使います。
ベンチマークの効果
さくらのクラウドの8コアの仮想サーバにて自作のDNS水責めベンチマークツールを使い検証を行いました。
dnsdistのみの検証のため、設定に
addAction( AllRule(), RCodeAction(DNSRCode.REFUSED) )
を設定し、すべてのクエリに即時 REFUSED
を返すように設定してあります。
初期状態
Listenerスレッドが1個の状態です。
# GOGC=500 ./prsd-bench4 -P 53 -H 192.168.10.50 --max-workers 1000 --max-length 8 --label 1 --zone example.com 2> /dev/null 2023-05-24 16:09:52.842209747 +0900 JST m=+10.002875416 resolved: 0.000000 query/sec, refused 231067.300000 query/sec, failed 72.200000 query/sec 2023-05-24 16:10:02.842144106 +0900 JST m=+20.002809775 resolved: 0.000000 query/sec, refused 220423.400000 query/sec, failed 144.400000 query/sec 2023-05-24 16:10:12.842143685 +0900 JST m=+30.002809354 resolved: 0.000000 query/sec, refused 230264.600000 query/sec, failed 144.400000 query/sec 2023-05-24 16:10:22.84215706 +0900 JST m=+40.002822729 resolved: 0.000000 query/sec, refused 220053.900000 query/sec, failed 144.400000 query/sec 2023-05-24 16:10:32.842160142 +0900 JST m=+50.002825810 resolved: 0.000000 query/sec, refused 227706.300000 query/sec, failed 144.400000 query/sec 2023-05-24 16:10:42.840047568 +0900 JST m=+60.000713237 resolved: 0.000000 query/sec, refused 232174.600000 query/sec, failed 144.400000 query/sec
20万qps以上は出ていますが、エラーもちらほらあります。
チューニング後
listenerスレッドを仮想コア数と同じ8個として、紹介したチューニングを全て入れている状態です。
# GOGC=500 ./prsd-bench4 -P 53 -H 192.168.10.50 --max-workers 1000 --max-length 8 --label 1 --zone example.com 2> /dev/null 2023-05-24 16:21:29.396835468 +0900 JST m=+10.001673734 resolved: 0.000000 query/sec, refused 417461.100000 query/sec, failed 0.000000 query/sec 2023-05-24 16:21:39.396746836 +0900 JST m=+20.001585106 resolved: 0.000000 query/sec, refused 445043.800000 query/sec, failed 0.000000 query/sec 2023-05-24 16:21:49.396666734 +0900 JST m=+30.001505003 resolved: 0.000000 query/sec, refused 431644.600000 query/sec, failed 0.000000 query/sec 2023-05-24 16:21:59.396818157 +0900 JST m=+40.001656423 resolved: 0.000000 query/sec, refused 438897.200000 query/sec, failed 0.000000 query/sec 2023-05-24 16:22:09.396665403 +0900 JST m=+50.001503669 resolved: 0.000000 query/sec, refused 440108.300000 query/sec, failed 0.000000 query/sec 2023-05-24 16:22:19.395664578 +0900 JST m=+60.000502848 resolved: 0.000000 query/sec, refused 425201.300000 query/sec, failed 0.000000 query/sec
エラーなく40万qps以上処理できるようになりました。
まとめ
権威DNSサーバであるNSDでは、UDPのバッファサイズ、recvmmsgの利用などはデフォルトで行われており、dnsdistパフォーマンスの調査をするにあたり参考にしました。
この記事がDNSサーバのパフォーマンスで困った際にお役に立てれば幸いです。
YAPC::Kyoto 2023でDNS水責め攻撃とGoによるベンチマーカの発表をしてきました #yapcjapan
YAPC::Kyoto 2023 に参加してきました!
数年ぶりに開かれたYAPCで、数年ぶりに会うエンジニアの同窓会みたいな雰囲気ありつつ、新しい参加者も多く最高でした。オフラインイベント楽しいです。スタッフの皆様ありがとうございました!! 京都まで行かせてくれた家族にも感謝
会場のKRPは2006年まで働いていた場所で、17年も経ってそこで発表する機会をいただいたのは個人的に感慨深いものがあります。はてなの大西さんの発表は自分にとってもとても懐かしく聞いておりました。
エモさしかない pic.twitter.com/6V8gpxx4bg
— 達人が教えるつぶあん🇺🇦 (@kazeburo) 2023年3月19日
発表してきた
私の発表はこちら
DNS水責め攻撃とその対策については1月に開催されたJANOG51 Meeting in 富士吉田でも紹介しております。発表について記事にしていただいているので詳しくはこちらを。
YAPC::Kyotoではここから派生して、Goによるベンチマーカ作りと高速なベンチマーカをつくるためのチューニングポイントを紹介しています。ベンチマークをとる、プロファイルを行うなども簡単ですが詰め込んでいます。ベンチマーカ自体のコードは公開していませんが、この資料が何かの参考になれば幸いです。
資料中に出てくるISUCON本はこちら
Go言語のベンチマークやプロファイリングについては mattn さんが書かれた「Go言語プログラミングエッセンス」がわかりやすくおすすめです。参考にさせていただきました。
オフラインイベントの体験をもっとたくさんのエンジニアに
いやぁ、ほんと行ってよかった。
この体験をたくさんのエンジニアに、特にコロナ禍で一度も経験していない若いエンジニアに味わって欲しい。YAPCは次回広島開催の話もあるし、他のカンファレンスでもオフライン増えてきているので積極的に参加するよう背中を押していきたい。そのためさくらインターネットや自分がお手伝いできることがあればお声がけいただけると嬉しいです。
YAPC::Kyoto 2023で話します! そしてチケットを今すぐに購入しましょう!!
YAPC::Kyoto 2023の採択トークが決まったようですね。面白そうなトークが沢山あってすごいですね。
私のトークも採択されました。ありがとうございます。ありがとうございます!!
こういう話をします。
クラウドファースト、クラウドバイデフォルトなどと言われるようにクラウドサービス前提にシステムの構築運用がなっています。インターネットにおける重要な基盤技術のひとつであるDNSにおいてもクラウドサービスが使われるようになっています。
本トークでは、さくらのクラウドのDNSアプライアンスサービスに行われたDNS水責め攻撃と呼ばれるDDoS攻撃の内容およびその対策について紹介します。また、対策にあたって作成したDNSサーバへ負荷をかけるベンチマーカを題材にハイパフォーマンスなベンチマーカを作る上で必要な要素も紹介します。
アジェンダ
* さくらのクラウド DNSアプライアンスとは(Perlも使っているよ)
* DNS水責め攻撃とその実際
* GoによるハイパフォーマンスなDNSのベンチマーカ作成
この話は、JANOG51 Meetingにて発表して内容に関連しているものとなります。資料の公開もしていますので、ぜひご覧ください。
発表のアーカイブ動画もこちらで公開されています。
チケットを買ってくれ
それはそうとして、そんなYAPC::Kyoto 2023ですがチケット販売が今月1月の31日までとなっています。
今月中にチケットを買わないと参加ができないのです! 今、まさにこの瞬間、すぐに買いましょう!!!!! 豪華ノベルティがついてくる個人スポンサーチケットは残席わずかとのこと!!
買いましたか?買いましたね。それでは会場でお会いいたしましょう!
今回会場となる、京都リサーチパークは以前働いていた場所で、そちらに久しぶりに行って、エンジニア仲間と会い、またしゃべれる機会があるということで非常に楽しみにしております。YAPC::Kyoto今からワクワクが止まりません!!
オマージュ元
買ってよかった2022
年末恒例
テレビ前に置くスピーカーを買った
Apple AirPlay 2対応でBluetoothのような煩雑なことがなく、すぐに音楽を鳴らせるし、音にも満足。
Dolby Atmos対応になったので、2本(?)ほど4K ULTRA HD Blu-rayを買った。
ロード・オブ・ザ・リングの方は劇場版とスペシャル・エクステンデッド・エディションのHDと4Kあわせて18枚セット。当然まだ全部みきれてない。
次はサブウーファーが欲しいな。Sonos Sub Miniかわいい。いつかのMac Proみたい。
ランニンググッズ
走るのは無料だと言ったな。あれは嘘だ。
前半は On の CloudMonster を履いていた。
何種類も履き比べてないのですが、地面に足を着いた時の安定性があった。今は普段履きとして使ってる。
後半はasicsのGlideRide 3。みなとみらいのスポーツゼビオで足の形を測ってお勧めされた中から選んだ。
足の運びはこちらの方がスムーズで走り方に合ってる気がする。
去年買った走る時のポーチもだいぶボロボロになってきたので新しくした。YURENIKUIのベルトタイプ。
体を挟むような形状になっていて安定しやすい。いつもは前に鍵、後ろにスマホをいれてます。
あと膝が痛くなることがあり、サポーターを買ってみた
タイツタイプと
膝サポーター
どちらも走るのが楽になってとてもよかった。
新しく買ったCW-Xのスポーツタイツ履いて気持ちよく走ってきた。
— 達人が教えるつぶあん🇺🇦 (@kazeburo) 2022年11月18日
脱ぐと「ゴンおまえだったのか、膝を支えてくれてたのは」となる
ただ、無理はよくない。1-2月、10月あたりは膝が痛く走るのをやめてウォーキングなどに切り替えていた。
12月はここまで133km程度。
体重も減ってる。
1月にハーフマラソン挑戦なのでがんばるぞー
本
今年つくったSRE室でチーム開発の体制もよくしていくための取り組みを開始している。そのひとつとして、「LeanとDevOpsの科学」は、さくらのクラウドのバックエンドチームのリーダーと一緒に読書会を始めた。
チームトポロジーは読みやすく、図もあるので社内で話するときにイメージが合わせやすいという利点ある。
社内で書籍購入制度が整備されたのでしっかり有効につかっていく所存。
来年は何買うかな~
sleepy コマンド
さくらのアドベントカレンダー2022 13日目の記事です。
サーバ運用を行なっていると、非同期で行われるサーバの設定反映や起動を待ったり、メンテナンス後に監視を再開する前にすこし待つなんてこともあるかと思います。
そんな時に、人力で3分待ったらコマンドを打つ、Webコンソールを操作するなんてやっていると人間「必ず」忘れます。監視のメンテナンスモードの解除などを忘れてしまうとそれこそ事故につながります。チェックリストを利用した対策もありますが、技術的に解決するのが望ましい姿です。
そこで、よくやってきたのがsleepコマンドと組み合わせて
sleep 180 && mkr update --st working
とする方法。(サンプルとしてMackerelでサーバのステータスを変更しています)
このように実行しておけば、自動で3分後にmkrコマンドが実行され、サーバの監視をもとに戻してくれます。この方法をしばしば使っていたのですが、ひとつだけ不満がありました。
それは、今どれくらいsleepしたのか分からない、あとどれくらいでmkrコマンドが動くのかを知りたいというものです。
date && sleep 180 && mkr update --st working
このようにdateコマンドを最初に実行すれば、あとどれくらいだろーと気になった時にターミナルに表示された時間と今の時間と見比べれば、あとどれくらいで完了するのかわかるかもしれません。が、もう少し怠惰にしたいです。
ということで、なんか作るかなと思いつつ、twitterでぼやいてみました。
プログレスバーがでるsleepコマンドがほしい
— 達人が教えるつぶあん🇺🇦 (@kazeburo) 2022年9月7日
すると、わずか19分後に完成していました。チャットAIさんもびっくりな速さです
眠たいので sleepy コマンド作った。 pic.twitter.com/9hP8cwUmKt
— mattn (@mattn_jp) 2022年9月7日
mattnさん速すぎです。
せっかくなので、自分の利用に合うように、小数点を含む秒数、infinityのサポートと経過時間の表示を追加してもらい、お仕事でも使ってます。
以下は監視を一時的に止めつつ、さくらのクラウドでサーバのスペックを変更する例。
mkr update --st maintenance <hostId> usacloud server shutdown <hostID> —zone <zone> -y usacloud server update <hostID> --zone <zone> --cpu 3 --memory 4 -y usacloud server boot <hostID>--zone <zone> -y sleepy 360 mkr update --st working <hostId>
複数台のサーバのスペックを変更していくような場合には状況が可視化されていると、心理的安全性高く作業にあたれますね。
電子書籍版5/30、紙版6/4「達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践」が発売されます!
共著で執筆しました「達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践」が発売されます。紙版は6/4日発売、電子書籍版は本日5/30から発売されております。通称 #ISUCON本 です。
ISUCONを例にするWebアプリケーションの主にサーバサイドのチューニングを広く扱うユニークな書籍となっております。ISUCONに参加する方はもちろん、業務でWebアプリケーションの開発運用にあたるエンジニアまで役に立ちそうな内容が盛りだくさんになります。
見本誌が届きましたが、分厚い、そして盛りだくさんな内容となっています。
技術評論社のページ
ISUCON本 出版記念のイベントも本日やります。お時間あるかた是非どうぞ
執筆者
著者は、ISUCONの初期から参加者として、あるいは出題者として深く関わってきた豪華メンバーです。
藤原俊一郎さん @fujiwara 2011年より面白法人カヤック。SREチーム所属。ISUCON優勝4回、出題3回 馬場俊彰さん @netmarkjp 株式会社X-Tech 5取締役CTO、株式会社iCARE技術顧問。ISUCON第一回にプロジェクターを持ち込んで参加しSELinux=Enforcingで入賞 中西建登さん @whywaita 株式会社サイバーエージェント所属。ISUCON8にて史上初の学⽣総合優勝 長野雅広 @kazeburo さくらインターネット株式会社所属。ISUCON1、ISUCON2、ISUCON9予選で問題作成。参加者として優勝も予選落ちも経験 金子達哉さん @catatsuy 株式会社PR TIMES開発本部長CTO。ピクシブ・メルカリを経て現職。ISUCON9予選・ISUCON6本選出題 草野 翔さん @rosylilly 宇宙海賊合同会社代表、株式会社ハンマーキットCTO、株式会社 Tech Consiglie CTO、プロモータル株式会社相談役、IPTech特許業務法人技術顧問。ISUCON9優勝、ISUCON4とISUCON10出題
目次
内容は次のようになっています。チューニングの基礎とモニタリングを最初に扱ったあと、負荷試験を紹介し、データベースやアプリケーションの高速化を扱い、最後にOSなど低いレイヤのチューニングについて書かれています。
また、付録として実際に9章までの知識を使っての private-isu のチューニングの事例、またISUCONのベンチマーカを実装するというなかなか対象読者が限られてしまいそうですが、知ると世界が広がる面白い内容もあります。
1章 チューニングの基礎知識 (@netmarkjp) 2章 モニタリング (@whywaita) 3章 基礎的な負荷試験 (@fujiwara) 4章 シナリオを持った負荷試験 (@fujiwara) 5章 データベースのチューニング (@kazeburo) 6章 リバースプロキシの利用 (@catatsuy) 7章 キャッシュの活用 (@catatsuy) 8章 押さえておきたい高速化手法 (@catatsuy) 9章 OSの基礎知識とチューニング (@whywaita) 付録A private-isuの攻略実践 (@fujiwara) 付録B ベンチマーカーの実装 (@rosylilly)
私の担当は、5章データベースです。データベースで扱う範囲は広く、本書の中で最もページ数の多い章となっています。NoSQL、NewSQLなどデータベースの種類を紹介し、データベースの負荷を知る方法として private-isuを題材にPROCESSLISTやスロークエリログ、pt-query-digestをあげ、そこで見つけた課題をインデックスやN+1を紹介することで解いていける内容となっています。
5-1 データベースの種類と選択 5-2 データベースの負荷を測る 5-3 インデックスでデータベースを速くする 5-4 N+1とは 5-5 データベースとリソースを効率的に利用する 5-6 まとめ
データベースは、ISUCONではありませんが、実際の業務ではクラウドのマネージドサービスを使うことがかなり多くなっているかと思います。執筆時にも悩みポイントではあったのですが、5章では具体的なクラウドの使い方は扱ってなく、ISUCONをベースに書かせていただいています。ISUCONの問題は今でも有用なものが多く、実際のクラウドでのパフォーマンスの問題も解決できるはずです。
本書のねらい
2019年のISUCON9の予選の問題を bokko, catatsuy, sota1235 とやらせていただいたのですが、そこで意識していたのは、着実にスコアがあがる設計をして、参加者の方にISUCONやパフォーマンスチューニングが楽しいと思っていただくということがありました。
この本もやはり、ISUCONやパフォーマンスチューニングの最初の一歩を踏み出せるよう書かせていただきました。プロファイリングを行い、そこから問題点を見つけ、修正する。そしてプロファイリングをしてみると、チューニングの作業は地味にみえるかもしれません。ただ、やれることが増え、目に見える形で結果が改善するとその分楽しくなるはずです。
内容が多く、一度に読むことは難しいかもしれません。1章から付録まで気になるところから行ったり来たり、繰り返し読んだりすることをお勧めします。
謝辞
技術評論社の皆様、共著者の皆様、レビューに協力していただいた皆様、ISUCONを運営しているLINE株式会社の皆様(特に@941さん)、大変ありがとうございました。