期間場所

先日、4月29日/30日に行われた、GMOの体験型ハッカソン？に参加してきました。

場所は北九州のGMOオフィスにて。

前泊をし、宿代とご飯代はGMOさんの方でごちそうになりました。（ありがたや〜）

オフィスの様子
北九州が感じられるいい感じのデザインだと思いました。
ワインセラーもあります笑（すごすぎたw）

夕方のオフィスからの眺めがめちゃくちゃ良かったです。使徒がやってきそうw

事前学習

今回のインターンは特別な気持ちで参加していました。

自分的な要因としては、3点挙げられると思います。

負けたくない気持ち（優勝グループに賞金10万円もらえる）
このインターンを通して実務インフラ知識を少しでも、ものにしたい気持ち
前回参加したサマーインターン後の選考（面接）で自分が学びを実体的に喋れなかったこと

春休みに旅行しまくった関係上、金銭的にもキツキツな中、いかにしてお金をかけずインフラ系の技術書を事前に読んでアウトプットできるかが重要だと感じアクション起こそうかなと思いました。

大学の工学部図書館から、技術書を取り寄せ、知識ゼロから毎日読みました笑

GWには完読できそうw

内容 as 印象的な内容

2日間で9つの課題をグループ間で解いて、ポイントを獲得し、そこで競争していきます。

【課題 - VM間のインターナル接続】
【課題 - Webサイトへの攻撃対処】
【課題 - Webサイトへの高負荷対処】
【課題 - 脆弱性調査対応】
【課題 -OS起動不可/サイト表示復旧】

etc...　

パフォーマンスチューニング

設問

他システムから移行してきたwordpressサイトが遅いとのこと。
ネット上の情報でチューニングしたが変わらないので、チューニングして欲しいと依頼がありました。

「多くのアクセスに対して」「正しい応答を返す」
ことを目指してチューニングを実施。アクセスはサイトのトップページだけではなく、各個別の記事にも行われる。

自分たちがやったこと

swapも起きていない・キャッシュは使われていて問題なさそう。

CPUにも特に異常はないことがわかったので、webサーバー周りをいじってみようかになりました。

FastCGI Cache

個々人が検索した結果これ良さそうじゃねってなりました。

クライアントからのリクエストに応じてphp等のプログラムを実行してhtmlページを作るページを動的ページといい。動的ページはプログラム実行・DBアクセスなどが入るため、サーバへの負荷が高く、レスポンスに時間がかかります。そこで、FastCGIキャッシュを使うとプログラムで生成した静的ページ結果をキャッシュしてクライアントに返すことで大幅にレスポンス時間を早くすることが可能です。

fastcgi_cache_path /var/cache/nginx/cgicache levels=1:2 keys_zone=cgicache:10m max_size=512M inactive=600m;

fastcgi_cache cgicache;
fastcgi_cache_valid 200 60m;

GZIP圧縮をした

gzip on
		[gzip]圧縮を有効にする
		`gzip_http_version`, 
		`gzip_proxied`,
		`gzip_min_length`,
		`gzip_comp_level`,
		`gzip_types`

参考
https://log.dot-co.co.jp/nginx-perfomance/
http://cloudrop.jp/wordpress/more_tuning_on_nginx

mysqlバッファープールを使用

メモリ領域であるバッファープールの値。
インポート短縮に関わらず、一般的にチューニングをする必要がある。
メインメモリの50～75%でよくチューニングされているらしい。

/etc/my.cnf

[mysqld]
innodb_buffer_pool_size=12G

引用：https://developers.gmo.jp/31447/

worker_processをautoにした

以上です。

Team-Cだったのですが、結果を見てくださいww(最強)

模範回答

nginx.confの設定

/etc/nginx/nginx.conf

worker_processes 1; #新規
worker_rlimit_nofile 30; #新規
events {
  worker_connections 40; # 1024→40
}
keepalive_timeout 0; # 65 → 0

worker_connectionsはworkerプロセスで開ける同時接続最大数です。

CPU使用率が高い時は、下げて接続を制限する。→ 今回はこれ⭐️
CPU使用率が低い時は、上げる。

keepalive_timeoutはタイムアウトせずに待つ時間のこと。
0なので無効状態。

nginx.serviceの設定

/usr/lib/systemd/system/nginx.service

LimitNOFILE=24 #追記

php設定

/etc/php/7.4/fpm/php-fpm.conf

process.max = 1 # 2→1にした
pm.max_requests = 10 #追記

コンテンツの更新がないとわかっていれば、mysqlのキャッシュのクリアやfastcgi_cacheも効果が大きいとのこと。

引用：https://log.dot-co.co.jp/nginx-perfomance/
qitta：https://qiita.com/mikene_koko/items/85fbe6a342f89bf53e89

カーネル修正作業

設問

あなたはwebサーバ（AmazonLinuxのローカルミラー）の管理担当者です。
来週セキュリティ監査があるとの連絡があったため、サーバのカーネルをアップデートしました。
その後にサーバを再起動したところ、ローカルミラーサイトのコンテンツが消失してしまいました。

何が起きているのか原因を調査し、新しいカーネルで起動してもローカルミラーサイトが表示できるように修正してください。
以下のURLで元サイトが表示されればOKです。

http://<チームのGrobalIP>/

起動画面確認のためwebコンソールが用意されています。

回答

アップデートして起動しなくなった。→　更新前を確認する。

web consoleを開いてサーバーを再起動する。→　1つ前のバージョンに戻す。

1つ前の状態

/var/www/htmlディレクトリが別ボリュームとして構成されている。（怪しい）

このボリュームがzfsで構成されている。（怪しい）
最新の状態
新カーネルではzfsモジュールが存在しなかった。（インストールからやられば）

実行手順

新しいカーネルで実行する
zfsのモジュールを追加する
zfsボリュームをマウントする

コマンド

yum update kernel-devel
【更新作業】カーネルモジュールのコンパイルには稼働しているカーネルのバージョンに合ったヘッダ等が必要なため、kernel-develパッケージをアップデートする。
dkms install -m zfs -v 2.19 -k 4.18.0- 425.13.1.el8_7.x84_64

【ビルド】dkmsを用いて、対象バージョン用の指定モジュールをビルドする。
modprobe zfs
【読み込み】ビルドしたカーネルモジュールを読み込む。depmodはすでにインストールされているため不要。
zpool import
アクティブになっていないプールを含めて表示。
旧バージョンカーネルで起動した際にプール名をメモしてあったならこの手順は不要。
zpool import zpool1
プールを読み込む。zfsファイルシステムが壊れていない、マウントポイントが設定されている、マウント先が存在し余計なファイルがない状態なら、この時点でマウントされる。
zfs mount zpool1/var_www_html

【確認】

uname -e 結果

4.18.0-425.19.2であること（最新）
df（ファイルの差分が見える）結果は下記が見えていること

zpool1/www_html 97G 62G 36G 64% /var/www/html
zpool1          36G 128K 36G    /zpool1

モジュールをビルドするとは？

ソフトウェア開発において、複数のソースコードファイルから構成される単一の実行可能なプログラムファイルやライブラリを生成するプロセスのこと。

dkmsとは？

ISまたはDynamicKernel Module Supportは、カーネル全体を変更することなく、個別のカーネルモジュールを更新できるようにするシステムです。

これを知っていたら解決が早かったかも。

Tips

めちゃくちゃいっぱいあるので一部ですが...

パイプ|で繋がれたコマンドは標準入出力をインターフェイスにしてデータを受け渡すことができること。
パブリックDNSサーバーは、一般的なインターネット利用者が使用するために公開されているものであり法律的に使っても問題ないこと。
インターナルIPの設定はyamlでかけてしまう。

etc...

気づき

普段は高レイヤーを勉強していますが低レイヤーも味があって面白いハッカソンでした。

全体を通して感じたことを2点ほどあります。

GMOさんつよつよ

GMOさんが普段やられている業務がいかに大変なものなのか（今回はインフラだったけど）、感じることのできる機会でもありました。

不正なアクセスが来ている場合、どういう仮説を立てて検証できるのかをしっかり考えさせていただけた最高の時間でした。

GMOさんのインフラエンジニアは常にこれをやっているんだろうな〜。

クラウドに頼るのもいいけど、低レイヤーも大事　→　実務に直結（障害対応できるか？）

世の中的にはクラウドしか勝たんの時代になっていて、それもすごく大事だと思います。

ただ根底に戻って「PC・サーバーはどういう動きをしているか？」

を知らずにDockerやクラウドに頼っているのはよろしくないなと肌で感じました。

今後、自分たちがWeb系のエンジニアとして仕事をする場合、セキュリティの問題は避けて通ることはできないのではないでしょうか？

その時に、どこで不正なアクセスが行われているのかをデバックするために、クラウド提供者に責任転嫁するのではなく、自分で解決できる人になっていきたいと感じました。

今後

一番はLinuxコマンドを打つことかなって思います。

データベースのパフォーマンスチューニングを学ぶ
Dockerを用いずに、LNMP環境を作る
英語のドキュメントを読める力を磨いていく

めちゃくちゃ濃厚な時間を過ごすことができました。帰りの飛行機が遅延していなければ、多分北九州に取り残されていた笑。

GMOさんありがとうございました！！！！

DevSecOpsThon2023 at GMO kitaQに参加してみた感想