モヒカンメモ

髪色が定期的に変わることに定評のある(比較的)若者Webエンジニアの備忘録

【 PHP 】 preg_match関数に渡せる正規表現の長さには上限がある

超長い正規表現をPHPのpreg_match関数に食わせたところエラーになった。

2022/9/30現在、公式ドキュメントにはこの振る舞いは記載されていないので調べたことを残しておく。

https://www.php.net/preg_match

エラーメッセージ

PHP Warning: preg_match(): Compilation failed: regular expression is too large at offset 32765 in php shell code on line 2

正規表現長すぎと怒られていることが読み取れる。

検証コード

# php -a
Interactive shell

php > echo PHP_VERSION;
8.1.9

php > $length = 32000;
php > while (true) {
php {     if (preg_match('/' . str_repeat('a', $length) . '/', 'x') === false) {
php {         echo "max:" . ($length - 1);
php {         break;
php {     }
php {     $length++;
php { }
PHP Warning:  preg_match(): Compilation failed: regular expression is too large at offset 32765 in php shell code on line 2
max:32764

※ 初期 $length を32,000としているのは、事前の調査で32,000ではpassして33,000ではエラーになることが分かっていたため

まとめ

preg_match関数の第一引数 ($pattern) として渡せる正規表現の長さは最大32,764文字。 それを超えると Compilation failed Warningが発生し、実行結果はfalseとなる。

ISUCON12 予選に参加して無残な敗退を喫した💀

恒例行事となっているISUCON予選に今年も参加し、無残な敗退を喫してきた💀

isucon.net

去年のブログ

blog.pinkumohikan.com

チーム紹介

チーム名は毎年見直していて今年は2時間にも及ぶ激論の末「 牡蠣食えば 金が無くなり リボ払い 」 (5-7-5) に、チームリーダーは怪しい野良抽選ツールによる厳正なる抽選(?)の結果 @nekodaisuki が務めることに。

nekodaisuki

  • リーダー
  • SQLの魔術師

cureseven

  • 歌手
  • 分析隊長

pinkumohikan

  • 肩もみがかり

振り返り

予選当日

記録: github.com

序盤は極めていい感じに動けており、遅いクエリのindexを調整したり、アプリ・DB分離を行ったり、データの使われ方に応じてテーブル設計を見直すなどして瞬間ランキングでは1位になったこともあった。「練習通りだ、今年は本戦行けるぞ!」このときは誰もがそう信じて疑わなかった。

瞬間ランキング 1位

中盤に差し掛かり、MySQLサーバの負荷が5%以下となった段階でSQLiteについて思いを馳せ始めた。 SQLiteは単体での性能は高いがスケーラビリティに欠けるのと単純に我々は慣れていないのでMySQLへ移行することにしたのだが、ここが難所だった。

不慣れなSQLiteとの対話、終わらないMySQLへのローディング...一進一退の攻防を繰り広げながら、最終的にはinitializeが時間内に終わらない問題を倒しきれずMySQL移行は失敗した。着手段階でMySQL移行が上手く行かない可能性はありそうだなと思いつつ、SQLite固有の施策を進めてMySQL移行完了後に2度手間になるのがやだなーと思ってSQLite周辺にあまり手を入れなかったのが良くなかった。さらに言えば、SQLiteで何ができるのかをしっかり調査せずに「SQLiteってtx使えなかったよね〜」などと勘違いしたまま進めてしまったのも良くなかった。

競技終了1.5時間ほど前の時点でMySQL移行が時間内に終わらない可能性の高まりを感じ、SQLiteのまま行くことことにやっと前向きになった。SQLiteで実行しているクエリのindexやクエリのチューニングをはじめたところすぐに4,000点ぐらい上がった。あと1時間あれば予選通過ラインには届いていそうな伸び率だっただけに、この判断をもう少しはやく出来ていれば...と思うなどした。

最終結果:

133位 / 698チーム中
from: https://isucon.net/archives/56838276.html

練習

練習には十分に取り組めた。 今年も10回近くの練習会を実施し、他チームとの合同練習会は背筋がピンとなるとても良い機会だった。 来年も同様の練習をしていきたい。

リーダー業のローテーション

いつチームが解散してもそれぞれがリーダーとして新チームを引っ張れる状態にしたいので、リーダー業をローテーションをしていきたいという思いがある。

これに関しては練習時はいい感じだったが、予選当日は (予選通過がかかっている事もあり) 進行や意思決定に少し口を出しすぎた感覚がある。 来年はもっとリーダーにリーダーらしい振る舞いをしてもらうための配慮をしたい。

課題

今回もめちゃめちゃ唸らされるおもしろい問題だった。 毎年毎年、そろそろ課題を出しつくたんじゃないか?って思うのに新たな唸りポイントを作れるのは本当にすごい。

技術的にもSQLiteはそれ自体は歴史があるが使われる箇所でいうと組み込みやネイティブアプリなどいわゆるWebエンジニアリングからはやや距離があるイメージだったが、最近ではCloudFlareがエッジコンピューティングに採用したりで注目度が上がっているので触れられてよかった。ファイルにすべての状態が閉じているので参照偏重なワークロードならアプリケーションとSQLiteと同梱して配布するなどすればコスパよくスケールさせられそう。

来年も対戦宜しくお願いします 🔥

指定したサイズ以上のファイルを見つける

どこにあるか分からないけどデカいファイルがあって悪さしていそうなので探したいときなどに、 find コマンドの size オプションが便利。

findコマンドにsizeオプションをつけるとファイルサイズで検索できる

findコマンド

ディレクトリやファイルを探せる便利なLinuxコマンド。

atmarkit.itmedia.co.jp

findコマンドのsizeオプション

容量の検索オプション。 例えば100MB以上のサイズのものを検索したければ -size +100M のような感じ。

$ man find
...
-size n[ckMGTP]
        True if the file's size, rounded up, in 512-byte blocks is n.  If n is followed by a c, then the primary is true if the file's size is n bytes (characters).  Similarly if n is followed by a scale indicator then the file's size is compared to n scaled as:

        k       kilobytes (1024 bytes)
        M       megabytes (1024 kilobytes)
        G       gigabytes (1024 megabytes)
        T       terabytes (1024 gigabytes)
        P       petabytes (1024 terabytes)

探してみる

前提:

$ ls -lh
total 614400
-rw-r--r--  1 pinkumohikan  staff   100M  8 15 06:18 100MB.txt
-rw-r--r--  1 pinkumohikan  staff   101M  8 15 06:18 101MB.txt
-rw-r--r--  1 pinkumohikan  staff    99M  8 15 06:18 99MB.txt

※ 各ファイルは dd if=/dev/zero of=100MB.txt bs=1M count=100 のようにカッチリ作ったもの

(1) 指定した容量のファイルを探す

$ find . -type f -size 100M
./100MB.txt

(2) 指定した容量よりも小さいファイルを探す

$ find . -type f -size -100M
./99MB.txt

(3) 指定した容量よりも大きいファイルを探す

$ find . -type f -size +100M
./101MB.txt

使われていない機能を積極的に消すべき理由

(プロダクト開発の文脈で) 使われていない機能は百害あって一理なしなので積極的に消すべきだと考えている。

使われていない機能は消すべき慈悲はない

とある日の某氏に降り掛かった悲しい出来事

消すべき理由1: プロダクトにおける "コア" の部分がハッキリする

たくさん機能があると何がコアなのか分かりづらくなる。「色々できることは分かったけど、何が強み(売り)なの?」という質問に答えにくくなる。

機能が減ればコアな部分が明確になる。コアが明確になると説明しやすくなる。説明しやすくなると営業しやすくなる。UIもシンプルになってお客さんにとっても使いやすいものになる。サポートにかかるコストも減る。開発者もどこを重点的に守る必要があるか分かる。

消すべき理由2: 機能の数は開発コストに直結する

売れることがバレれば競合はどんどん増えるし、時代が変われば求められているものが変わる。一度システムを作ればそれをずっと提供し続けられるわけではない。

機能が増えるとシステムの複雑度があがる。複雑度が上がるとシステム全体を理解しづらくなり、開発コスト(変更コスト)があがる。拡張をどんどん続けているサービスでは1年前は7日で作れたものが今では1ヶ月かかるとかはザラ。そのままにすると開発者はいなくなる。

余談としては設計を見直すことで複雑度を下げるというアプローチもある。それも大事だけど、使われていないものを消すほうがリスクが低いし手っ取り早い。

もったいない気持ちとの戦い

ある機能も一度はコストをかけて作られたもの。それを捨てようとしたら "もったいない" と思うのはごく自然なこと。

でも、使われていないということは価値を生んでいないということ。そして使われていない機能を消すべき理由に対して逆説的に、 機能は存在しているだけでコストが発生していると言える。

"価値を生んでいないのにコストが発生するもの"、捨てたくありませんか?

さくらのレンタルサーバ上で Node.js (npm) を使えるようにする

諸般の事情でさくらのレンタルサーバ上で Node.js (npm) を使いたくなったので、調べたことやインストール手順を残しておく。

前提:

  • 2022年5月時点の情報
  • さくらのレンタルサーバではNode.js (npm) は提供していない (ので使えるようにすることも含めてすべて自己責任)

選択肢

(1) パッケージマネージャでNode.jsをインストールする

さくらのレンタルサーバはFreeBSDというOSが使われていて、FreeBSDではパッケージマネージャとして packagesports が使えるらしい。

[pinkumohikan ~]$ uname -s
FreeBSD

https://docs.freebsd.org/ja/books/handbook/ports/

さくらのレンタルサーバはいわゆる "レンタルサーバ" なので、パッケージをグローバルインストールするのに必要なroot権限は (当然) 利用者には与えられていない。そのためパッケージマネージャを利用してNode.jsをインストールすることは出来ない。

(2) バイナリをダウンロードして使う

macOSやLinux等のメジャーOS用のバイナリは公開されているが、FreeBSD用の公式Node.jsバイナリは配布されてなかった。

https://nodejs.org/ja/download/

Download Node.js (npm) Binary

(3) バイナリをコンパイルして使う

Node.jsはOSSなのでソースコードが公開されている。

https://github.com/nodejs/node

コンパイルに必要なアレコレ (gccとか) はさくらのレンタルサーバへインストールされていたので、Node.jsのソースコードをダウンロードして自分でコンパイルすることでNode.js (npm) を使うことができそう。

Node.jsのインストール

今回は「(3) バイナリをコンパイルして使う」の方法でNode.jsを使えるようにしていく。

(1) OpenSSLをコンパイルする

標準で使えるOpenSSLはバージョンが古くてNode.jsのビルドに使えない (※) ため、新しめなOpenSSLをダウンロード & コンパイルする。

https://www.openssl.org/

[pinkumohikan ~/openssl]$ curl -sSf https://www.openssl.org/source/openssl-1.1.1o.tar.gz -O
[pinkumohikan ~/openssl]$ tar zxf openssl-1.1.1o.tar.gz

[pinkumohikan ~/openssl-1.1.1o]$ ./config --prefix=/home/pinkumohikan/openssl --openssldir=/home/pinkumohikan/local/openssl
[pinkumohikan ~/openssl-1.1.1o]$ make
[pinkumohikan ~/openssl-1.1.1o]$ make install

(2) Node.jsをコンパイルする

2022年5月時点の推奨LTSはNode.js 16系だが、Node.js 16からPython 3必須になる問題 (※) があって都合が悪いので今回はNode.js 14を使うことにする。

https://nodejs.org/ja/download/

[pinkumohikan ~]$ curl -sSf https://nodejs.org/dist/v14.9.0/node-v14.9.0.tar.gz -O
[pinkumohikan ~]$ tar zxf node-v14.9.0.tar.gz

[pinkumohikan ~/node-v14.9.0]$  ./configure --shared-openssl --shared-openssl-includes=/home/pinkumohikan/openssl/include/ --shared-openssl-libpath=/home/pinkumohikan/openssl/lib/
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'openssl', required by 'virtual:world', not found
Node.js configure: Found Python 2.7.18...
INFO: configure completed successfully
[pinkumohikan ~/node-v14.9.0]$ export LD_LIBRARY_PATH=/home/pinkumohikan/openssl/lib
[pinkumohikan ~/node-v14.9.0]$ nohup make install DESTDIR=/home/pinkumohikan/local PREFIX=

make install には数十分かかるのでコネクション切断に備えてnohupつけておくのがオススメ。

(3) Pathを通す

モノができたらあとはパスを通すだけ。

[pinkumohikan ~/node-v14.9.0]$ echo "export PATH=$PATH:~/local/bin
export LD_LIBRARY_PATH=/home/pinkumohikan/openssl/lib" >> .bashrc

ログインし直すか source .bashrc して

[pinkumohikan ~]$ node -v
v14.9.0
[pinkumohikan ~]$ npm -v
6.14.8

完。

備考

OpenSSLが古くてNode.jsのコンパイルに使えない問題

標準のOpenSSLを利用してNode.jsをコンパイルしようとすると下記のようなエラーが出る。

[pinkumohikan ~/node-v14.9.0]$ make
...
../src/node_crypto.h:72:46: error: use of undeclared identifier
      'EVP_MD_CTX_free'; did you mean 'EVP_MD_CTX_create'?
using EVPMDPointer = DeleteFnPtr<EVP_MD_CTX, EVP_MD_CTX_free>;
                                             ^~~~~~~~~~~~~~~
                                             EVP_MD_CTX_create
[pinkumohikan ~]$ openssl version
OpenSSL 1.0.2o-freebsd  27 Mar 2018

GitHub Issueを軽く読んだ感じOpenSSLが古いせいらしい。

https://github.com/nodejs/node/issues/22025

Node.js 16からPython 3必須になる問題

さくらのレンタルサーバではPython 2系までしか使えないので、Python 3系が必須となるNode.js 16系は入れられない。

[pinkumohikan ~/node-v16.15.0]$ ./configure
Node.js configure: Found Python 2.7.18...
Please use python3.10 or python3.9 or python3.8 or python3.7 or python3.6.

Node.js 14系までならPython 2系でいける。

ただ、Python 3を自前コンパイルすればNode.js 16系もいけそうな気がするので誰か試してみて欲しい。

https://www.python.org/downloads/

参考にした資料

PHPUnit実行時にメモリ使用量制限に引っかかる場合の対処方法

たくさんのテストケースを抱えるプロダクトでPHPUnitを実行した際、下記のようなエラーが表示されることがある。

エラーメッセージ:

$ ./vendor/bin/phpunit
...
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

これはPHPのメモリ使用量制限 (memory_limit) を超えてメモリを確保しようとしたためPHPがプログラムの実行を中断したことを示すエラーメッセージ。

対処方法

メモリをたくさん使っているテストケースを見つけていい感じに直すという方法もあるが、元々PHPはメモリどのぐらい使うかとかは些細なこととしてあまり気にしない文化だと思うので (メモリ10GB食うみたいなアホみたいな状態でない限り) メモリ使用量制限を引き上げて凌ぐのが良いと思う。

(1) phpunit.xmlでメモリ使用量上限を引き上げる

PHPUnitの設定ファイル phpunit.xml に設定を書くことで、PHP設定を一時的に変更した状態でPHPUnitを実行することができる。

phpunit.readthedocs.io

デフォルト128MBから512MBへメモリ使用量上限を引き上げたければ下記のように変更する。

--- a/phpunit.xml
+++ b/phpunit.xml
@@ -2,5 +2,6 @@
 <phpunit>
     <php>
         <env name="APP_ENV" value="test"/>
+        <ini name="memory_limit" value="512M"/>
     </php>
 </phpunit>

個人的にはこの方法が一番妥当だと思うのでおすすめしたい。

(2) PHP実行時オプションでメモリ使用量上限を引き上げる

php コマンドにある -d オプションで一時的にPHP設定を変更することができる。

$ php --help
Usage: php [options] [-f] <file> [--] [args...]
...
  -d foo[=bar]     Define INI entry foo with value 'bar'
...

例:

$ php -i | grep memory_limit
memory_limit => 128M => 128M   # ← デフォルトでは上限128MB

$ php -d "memory_limit=512M" -i | grep memory_limit
memory_limit => 512M => 512M   # ← 一時的に上限512MBへ引き上がっている

これまで ./vendor/bin/phpunit ./tests のようにPHPUnitを実行していた場合、 php -d "memory_limit=512M" ./vendor/bin/phpunit ./tests のようにして実行時オプションを指定する。

(3) php.iniでメモリ使用量上限を引き上げる

PHPの設定ファイル php.ini でメモリ使用量上限を変更することができる。

www.php.net

f:id:pinkumohikan:20220115200027p:plain
リソース制限: memory_limit

ただし、php.iniの影響範囲はシステムグローバルとなるので、特定のツール (PHPUnit) のためだけにグローバルな設定を変えるというのはあまりお行儀が良くないようにも思う。

古めのLaravelアプリがComposer 2で動かない問題

少し古めのLaravelアプリケーションを保守していてComposer 2で composer install 出来ない問題にぶち当たったので、これから躓くひとのために記録を残しておく。

f:id:pinkumohikan:20211121151059p:plain
Error: @php artisan package:discover --ansi In PackageManifest.php line 131: Undefined index: name

ざっくりまとめ

  • Composer 2になってComposer 内部データファイルのデータ構造が変わった
  • LaravelにはComposer 内部データファイルを参照する処理があるため、パッチが当たる前のLaravelではComposer 2で動かない
  • Composer 2を使いたければ、その前にLaravel 6.18.7、7.6.0以上へバージョンアップが必要

エラーメッセージ

$ composer --version
Composer version 2.1.12 2021-11-09 16:02:04

$ composer install
...snip...
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi

In PackageManifest.php line 131:

  Undefined index: name


Script @php artisan package:discover --ansi handling the post-autoload-dump event returned with error code 1

ざっくり解説

LaravelにはPackageManifestというクラスがあり、こいつはComposerの内部ファイルを参照する。

github.com

Composer 2になって内部ファイルのデータ構造が変更されたので、新データ構造に対応していない古いLaravelアプリケーションでは上述のエラーが起きる。

LaravelのIssueとしてはこれ。

github.com

上記Issueで作られたパッチがそれぞれ下記バージョンで取り込まれている。

github.com

github.com

ので、上記以上にLaravelをバージョンアップすることでComposer 2でも動くようになる。

検証

パッチが適用される前のlaravel/framework v7.5.2では動かない

bash-4.2# composer --version
Composer version 2.1.12 2021-11-09 16:02:04

bash-4.2# composer require laravel/framework:7.5.2
./composer.json has been updated
...snip...
> @php artisan package:discover --ansi

In PackageManifest.php line 131:

  Undefined index: name


Script @php artisan package:discover --ansi handling the post-autoload-dump event returned with error code 1

パッチが適用された後のaravel/framework v7.6.0なら動く

bash-4.2# composer --version
Composer version 2.1.12 2021-11-09 16:02:04

bash-4.2# composer require laravel/framework:7.6.0
./composer.json has been updated
...snip...
> @php artisan package:discover --ansi
Discovered Package: facade/ignition
Discovered Package: fideloper/proxy
Discovered Package: fruitcake/laravel-cors
Discovered Package: laravel/tinker
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Package manifest generated successfully.
69 packages you are using are looking for funding.
Use the `composer fund` command to find out more!

bash-4.2# echo $?
0

🎉

ISUCON11予選 31位で惜しくも本戦出場ならず〜〜〜

今年もISUCON 予選に参加し、527チーム中31位で惜しくも本戦出場なりませんでした、くやしい〜〜〜〜〜〜〜。

f:id:pinkumohikan:20210822220237p:plain

ISUCONとは

Iikanjini Speed Up CONtest。LINE社主催、お題となるWebアプリケーションをガツガツゴリゴリいじくり回して超たくさんの人が同時に使っても死なないチョッパヤ仕様にするソフトウェアエンジニア向けのエクストリームイベント。

isucon.net

今回のオンライン予選は598チーム、1421名の方にご参加いただきました。

チームメンバー紹介

今回はチーム 「牡蠣に当たるときの効果音→カキーン」 として、下記メンバーで参加しました。

cureseven

  • アプリの改修頑張った
  • 練習熱心
  • すぐ歌い出す

shiningcureseven.hatenablog.com

nekodaisuki

  • 猫がだいすき
  • インフラがちゃがちゃマン
  • SQLの魔術師

sinnderu.hatenablog.com

pinkumohikan

  • 色々指図するマン
  • やったこととスコアをIssueに書かないとキレる担当

主な施策

やったことの全容↓ github.com

1. index追加

Slow query logを見ながらindexが必要そうなところへペタペタ。 降順インデックスの罠は 進研ゼミ ISUUMOでやったやつ。

2. インフラ構成の変更

最初は1台のインスタンスに全盛りで、CPUをnginx, app, dbで食い合っていたのでDBサーバを別インスタンスへお引越し。 MariaDBには慣れてないからMySQL 5.7に変更、後に降順インデックス使いたかったのでMySQL 8へ。

最終的にはappサーバのCPUがフィーバーしていたのでappだけのサーバも用意して下記のような構成に。

サーバ 役割
1 nginx, varnish, app
2 app
3 DB

3. dropProbabilityの調整

チューニングが進み、リソースに余裕が出てきたタイミングでいじいじ。 5%刻みで設定変えてベンチ回して、最もスコアが良かった 0.95 に設定。

ただこれは13:30に設定して以降ずっとそのままだったのである程度チューニングが進んだ段階で見直したほうが良かったと反省。

4. lastなIsuConditionをメモリに持たせる改修

最新のIsuConditionを取得しているところやN+1があり、クエリで一括取得するようにしても良いけどDB負荷高めだったのと最新レコードだけならデータ量的にも行けそうだったのでアプリのメモリに持たせる方向で解決。

結構重要な仕事を無事成し遂げられたcureseven氏に拍手。ベースとなるデータを作る部分ではnekodaisuki氏のSQL力がいかんなく発揮された。

5. リバースプロキシでのコンテンツキャッシュ

最初はnginxのproxy cacheでキャッシュしてたけど最小キャッシュ時間が1sなのでタイミングによって鮮度古いよエラーが出ちゃう問題があり、途中からvarnishを挟んだ。

が、varnishは全然練習してなかったので手こずってた模様。自分も最後にvarnish触ったのは7年前とかなのでnekodaisuki氏に血を吐いてもらった。

振り返り

一言で表すと、去年と比べてチームとしても個人としても良い感じに進められ、チームビルディングや練習の甲斐あって成長が感じられる良い回でした。

競技中は終始良い雰囲気で進められたし、みんながしっかりログを見ながら「この辺が遅そう」みたいな当たりを付けながら進められていたので来年は誰がリーダーになってもやっていけそう。スコアも頻繁にリーダーボードに乗るぐらいには健闘していた。

去年本戦に出場できたのはまぐれじゃないぞと証明するため今年もチームで10回ぐらい練習会をしたものの、最終スコアは92336点 31位でわずかに25位に届かず予選敗退。 5万点ぐらい足りなかったら実力不足だと割り切れるけど予選通過ラインが106094点ぽく、競技終盤のスコアは10.7万ぐらいだったのでワンチャン届いていたなーと思えてしまって大変悔しい。

f:id:pinkumohikan:20210823010925p:plain

とは言え運も実力の内、むしろ運に左右されない強靭なスコアが必要。また来年がんばるぞ。

今回の問題も大変良い問題でした。 大きなボトルネックがドーンと構えている感じではなく、改善すべきポイントが各所にあって改善のたびに着実にスコアが伸びてコツコツとスコアを積み上げていけるタイプの問題。ベテランはもちろん、ISUCON初心者でも楽しめる課題だったと思います。ISUCON入門イベントとかに使えそう。

来年も対戦宜しくお願いします!

AmazonLinux2にMySQLクライアントのみをインストールする

AmazonLinux2にMySQLクライアントのみをインストールしたくなって方法を調べたのでまとめておく。

前提

1. OS

$ grep PRETTY_NAME /etc/os-release
PRETTY_NAME="Amazon Linux 2"

2. 初期状態ではAmazonLinux2にはMySQLクライアントは入っていない

$ mysql --version
-bash: mysql: コマンドが見つかりません

3. 接続先はAurora MySQL 2系

4. 2021/07/27 (火) 15:00時点の情報

インストール手順

1. MySQLのyumリポジトリをインストール

AmazonLinux2のデフォルトyumリポジトリではMySQLクライアントパッケージがどこにあるかが分からない。在り処を教えるためにMySQLのyumリポジトリをインストールする。

$ sudo yum install -y https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
...
インストール:
  mysql80-community-release.noarch 0:el7-3

完了しました!

上記のURLはAmazonLinux2 (Red Hat Enterprise Linux 7 / Oracle Linux 7) 用なことに注意。AmazonLinux 1系やCentOS 8系にインストールする場合は上記URLではダメなので、下記から対応するURLを取得すること。

dev.mysql.com

2. MySQL 8系のリポジトリを無効にする

初期状態ではMySQL 8系のリポジトリが有効になっている。

今回はAurora MySQL 2系に接続したくて、Aurora MySQL2系はMySQL 5.7系互換。ゆえに、MySQL 8系よりもMySQL 5.7系用のMySQLクライアントを使ったほうが不都合が少ない。

$ sudo yum-config-manager --disable mysql80-community
読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd
=============================================== repo: mysql80-community ===============================================
[mysql80-community]
...

$ sudo yum-config-manager --enable mysql57-community
読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd
=============================================== repo: mysql57-community ===============================================
...

ちなみに、どっちも無効にしておいてMySQLクライアントをインストールするときに --enablerepo=mysql57-community みたいに指定する方法もある。

3. MySQLクライアントをインストールする

MySQLクライアントは mysql-community-client というパッケージ名で登録されている。あとはyum installを叩くだけ。

$ sudo yum install -y mysql-community-client
読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd
mysql-connectors-community                                                                      | 2.6 kB  00:00:00
mysql-tools-community                                                                           | 2.6 kB  00:00:00
mysql57-community                                                                               | 2.6 kB  00:00:00
mysql57-community/x86_64/primary_db                                                             | 279 kB  00:00:00
45 packages excluded due to repository priority protections
依存性の解決をしています
...
インストール:
  mysql-community-client.x86_64 0:5.7.35-1.el7                  mysql-community-libs.x86_64 0:5.7.35-1.el7
  mysql-community-libs-compat.x86_64 0:5.7.35-1.el7

依存性関連をインストールしました:
  mysql-community-common.x86_64 0:5.7.35-1.el7          ncurses-compat-libs.x86_64 0:6.0-8.20170212.amzn2.1.3

置換:
  mariadb-libs.x86_64 1:5.5.68-1.amzn2

完了しました!
[ec2-user@ip-10-0-101-190 ~]$ mysql --version
mysql  Ver 14.14 Distrib 5.7.35, for Linux (x86_64) using  EditLine wrapper

じゃじゃーーん!

参考にした資料

dev.mysql.com

docs.aws.amazon.com

IPA 情報処理安全確保支援士試験に合格しました

IPA主催のサイバーセキュリティ知識の認定試験「情報処理安全確保支援士試験」(旧 セキュリティスペシャリスト試験)に合格しました 🎉

f:id:pinkumohikan:20210718150045p:plain

情報処理安全確保支援士試験とは

「情報処理安全確保支援士試験(SC)」はIPA 情報処理推進機構 主催のIT認定試験で、「応用情報技術者」の上位に位置してサイバーセキュリティ分野での専門知識について認定する試験。

www.jitec.ipa.go.jp

サイバーセキュリティリスクを分析・評価し、組織の事業、サービス及び情報システムの安全を確保するセキュリティエンジニアや、技術・管理の両面から有効な対策を助言・提案して経営層を支援するセキュリティコンサルタントを目指す方に最適です。

制度改定により今は「情報処理安全確保支援士試験」と呼ばれているが、昔は「セキュリティスペシャリスト試験」という名前だった。

IPA 高度系試験のなかでは比較的合格しやすいと言われているが、合格率で言うと20%ちょいなのでそれなりには難しい。

f:id:pinkumohikan:20210708133816p:plain
合格率

IPA 高度系試験にしては唯一、春期と秋期の両方で受験可能なのが素晴らしい。

f:id:pinkumohikan:20210708133601p:plain 出典: https://www.jitec.ipa.go.jp/1_13download/youkou_ver4_6.pdf

受験の動機

  • Webエンジニアの強みとしてセキュリティ知識を深めたい
  • Webエンジニアとして競争力を維持するために、能力の向上と証明をしておきたい
  • IPA 高度試験合格という響きがカッコいい
  • 同時期にWebセキュリティ実務知識試験 (通称: 徳丸実務知識試験) を受けたので続けて受けると学習効率が良かった

実は春期ではデータベーススペシャリストを受けるつもりだったが新型コロナウイルスの影響で試験時期が半期ズレたらしく春期では受けられなかったので急遽、情報処理安全確保支援士試験に変更したという裏話もあったり。

受験勉強としてやったこと

受験勉強としては過去問道場でひたすら過去問を解きながら分からないことや事例をググり、仕上げとしてTACの本を軽く読んだ。

振り返り

受験勉強をしたことで応用情報範囲の復習ができたり、サイバーセキュリティ周辺の知識が増えたり、サイドチャネル攻撃みたいな「言われてみれば確かにそういうことできそう」みたいな面白い攻撃手法について知れたことは良かった。

サイバーセキュリティの知識については徳丸試験対策やら過去問道場やらTAC本やらでそれなりに対策ができていたが、試験3日前ぐらいに午前Ⅰ試験の出題範囲が全然違うことに気づいて大急ぎで応用情報対策を始めたのは失敗だった。ちゃんと出題範囲を確認しましょう(遠い目)。

あと勉強の進め方として、TACの本は思っていたよりもしっかりと個々の技術について解説がされていたので最初にこっちを通読してから過去問道場で修行するほうがが学習効率が良さそうに思った。

余談

これから同試験を受けられるかたで過去問道場を使われるかたは、試験が近づくにつれて過去問道場が重くなっていくことに注意されたし。

前日ぐらいからページ読み込みに2 - 3秒かかるようになり、試験当日は30秒待っても開かないぐらいでまともに使えなくなる。過去問道場には間違った問題を再出題してくれる便利機能があるので試験直前の追い込みに使おうと思っていたのに、当日使い物にならなくて予定が狂った。

余談2

最近はエンジニア採用のお手伝いもしているので「技術力があること」をどうやって見極めるかについて関心がある。今回受験してみて、同試験の合格者なら運用保守(障害対応)の技術力について一定の担保が出来るんじゃないかなーって思ったりした。

f:id:pinkumohikan:20210726124038p:plain
情報処理安全確保支援士合格証書