子どもとお参りに行って帰りにココス 子どもは書道「明るい心」、提出宿題は書道のみ おせちは毎年恒例Oisix、数の子が美味しかった 嫁の熱が下がらないので#7119へTELから休日急患病院へ、多分インフルが治ったあとにマイコプラズマ肺炎疑惑 子どもが寝たあとはスプラ、バンカラマッチオープンのみ、オープンならそこそこ勝てるが、、、

概要 今年も残りあと一日。 Xに流れてくる人々の振り返り記事を見ていたら、自分も書いたほうがいいなという気持ちになったので31日だけど書くことにした。 仕事 今年は自分にとっては今までにない学びが多い年になった。 チームリーダーとして昨年夏頃からやることになり、今までよりも重責ではあったのだが、周りに助けられてなんとかチーム運営を行っていた。 技術的にも、マネージメント的にもリーダーシップを発揮するよりも、フォロワーシップを発揮するほうが自分には合っていたし、そもそもチームメンバー全員が優秀で誰もがリーダーになってもおかしくない状況だったので、自分に出来る範囲でフォローにまわることとしていた。 それは一部はうまくいっていたと思っていて、各メンバーが自走しやすい土壌ができていたと感じている。 反面、強いリーダーシップが必要ない状態で、リーダーとして自チームがどうあるべきか、今後チームとしてどこを目指していくかという考えも段々と薄れていってしまったことは反省点にある。 それが求められたいたのかということもわからず、だからと言って自ら問うこともしなかったのは大いに反省している。 とは言え、チームの状態も変わったので自分がリードを続けるかはわからないが、エンジニアとしても一つ良い経験にはなった。 いちメンバーとして考えていた時の技術的課題や組織課題と、リーダー視点で考えるそれらに実際にどこまで違いがあるかと問われれば大きな違いは無いはずだが、少なくともメンバーだった頃の私は今ほどは考えられていなかったし、メンバーやマネジメントラインと会話を重ねたことは自分にとっては大きな糧になったと言える。 プライベート まずは、家を購入したことが最も大きいライフイベントだった。 今住んでいる家の近場で、新築建売、中古戸建て、中古マンションを見たものの、東京23区は土地も建物もとんでもない勢いで高騰しており、我々の予算範囲内では中々納得できる物件は見つからず、最終的には自分たちが納得出来るものをということで都内近郊で注文住宅を購入することとなった。 今は私はリモートワーク中心で妻はほぼ出社（週一リモート）という状況なのだが、昨今のビッグテックの出社回帰の状況を鑑みるに、リモートワーク中心で場所を選ぶわけにもいかず、現状を維持出来て場合によってはフル出社になっても問題なさそうなところを土地として選んだ。 土地もかなりの数のデータを見てスプレッドシートにまとめたりもしたのだが、やはり23区は難しかったものの、最終的な決断はすぐだった。 そんなこんなで春先に契約した家も、もう年末には形が出来ており、もうすぐ完成するところまでやってきた。 子供の転校や通勤などのライフサイクルが安定するまでは、なかなか気が休まらないとは思うので一抹の不安はどうしても抱えてしまうが、夢にみたマイホームということで大きな楽しみでもある。 なお、自分の人生には縁遠いことと半ばあきらめていた防音室だが、完全防音では無いものの、自分の作業部屋を生活空間としてはバランスが良い程度の防音性能を備えることになったのでそれはそれは楽しみである。 ただ、引っ越しだけは本当に面倒で今からすでに気が重い。 健康面では、不定期ではあるもののジム通いが継続でき、3月にハーフマラソンに久しぶりに出られたのは大きい。 健康診断では相変わらずLDLコレステロール値が謎に高いものの、尿酸値などは通常値まで下がったので、引き続き運動は継続していきたい。 引っ越してもジムを探すか、少し先に土手があるので土手をランニングするでもいいかなと思っている。 最近同僚がミニベロを購入したと聞いて自分も少し気になり始めている所だが、電動バイク（50cc扱い）に中型バイク（250cc）と車（今年購入）と家族が使う電動アシスト自転車(自分も乗る)まであって、ロードバイクは流石に…となっているのでまだ押し留まっている所。 総括 2023振り返り と比べるとだいぶ異なるテイストになっているのだが今年も中々濃い一年だったし、色々と考えさせられた年でもあった。 30代最後の年としては良い一年だったのではなかろうか。 また、来年も色々もがき悩みながら頑張っていきたい（40は不惑だけども）。 今年もお世話になりました。

感想 オライリーから出ている「EfficientLinuxコマンドライン」を読み終えた。 EfficientLinxコマンドライン: Amazonリンク サーバーインフラエンジニア、およびSREとして10数年やってきた身としては、知っている項目も多く、完全に初見だったものは少なかったものの、シェルの管理やAWKの便利な使い方などは学びになった。 また、ターミナル操作時には改めてシェルと向き合って、意識的に改善をしていく良いきっかけになったと思う。 本書籍は、プログラマーやインフラエンジニアとして経験が浅い方など、ターミナルに不慣れだったりLinuxコマンド操作に不安があるかたには最適な書籍だと思う。 初心者がいきなり読んでも難しいかもしれないが、ターミナルが仕事のツールとして当たり前の環境の方にはかなり手助けになりそうである。 別途AWKのオライリー本も最近改訂されたので、そちらも読んでみようかと思う。

概要 tmuxとはターミナルマルチプレクサの略で、主にターミナルで複数のセッション管理ができるツールである。 セッション管理以外にも画面分割をしたり、Vimのキーバインドでターミナル内の文字列をコピー&ペーストができる。 10年以上前に教えてもらって長らくターミナルと組み合わせて使っていたのだけど、最近ではSSHをすることも少なくなり、セッション管理としての用途はほぼ使わなくなってきたものの、画面の分割やコピペはまだまだ重要な機能として使っている。 特に、証跡としてterraform plan結果をガッとコピーしてSlackのテキストスニペットに貼り付けるなどで多用しているし、ターミナルを遡るスクロールにもVimキーバインドが便利なので活用していた。 課題 先述の通り、セッション管理としてはほぼ使っておらず、無くても困らなくなってきた。 なので画面分割とコピペができれば十分なのである。 また、tmuxはどうしても重くなりがちで、zshのcompletion系も相まって、起動が遅かったりする。 他にもVSCodeのターミナルとtmuxの相性が悪かったりするので、VSCodeのターミナルモードをやめることにもなった。 長らくiTerm2+tmuxを使っていたが、数年前にやめてVSCode+tmuxにしつつ、バグったりするのが嫌でこの間までAlactritty+tmuxを使っていた。 AlacrittyもRustで書かれていて動作は軽快だったが、複数ウィンドウを作成できないことからtmuxを抜け出せずにいた。 そこで、Weztermにたどり着いた。 要件 複数ウィンドウを管理できる Vimキーバインドでコピー&ペースト、移動ができる Vimキーバインドで画面の分割ができる 使ってみて まず、WeztermはAlactittyと異なり、アプリケーション側で複数のウィンドウをタブで管理ができる。 つぎに設定ファイルをLuaで記述することができ、かなり柔軟に対応することができる。 結果、下記の設定で、tmuxの画面分割、およびVimキーバインドでコピー&ペーストができるようになった。 $HOME 直下にある ~/.wezterm.lua が設定ファイルなので修正すればOK. -- Pull in the wezterm API local wezterm = require 'wezterm' -- This will hold the configuration. local config = wezterm.config_builder() local config = { -- Font font = wezterm.font { family = 'Hack Nerd Font Mono', weight = 'Bold', }, font_size = 16.

納車 先週の日曜日、ついに待ちにまったCX-30 20s Retro Sports Editionが納車だった。 納車はいつもの打ち合わせスペースではなく、3階の特別スペースで行われた。 保険の契約や最終納車手続きをiPadで実施するもので、全てシステム化されていたのは流石というところ。 煩雑な手続きにひたすらボールペンで文字を書くというのは、終わりを迎えつつあるのかもしれない。 20s Retro Sports Edition これはノーマルのエディションよりも価格が高い。 その代わりに革張りだったり、ブラックのホイールやフロントパネル、サイドミラーに加えて、BOSEのスピーカーが標準搭載されている。 車で音楽やラジオを聴くのが好きなので、これは嬉しいオプションである。 HONDAのヴェゼルと比較検討したところ、価格が30万くらいヴェゼルのほうが高かったというのはあるものの、最終的にこのオプションで決定したと言っても過言ではない。 ジルコンサンドメタリックというちょっと変わったカラーではあるものの、この渋い色がとても気に入っていて、これにブラックなポイントがついているのが最高にカッコいい。 新車を手に入れたのは人生で初めて。大事に長いこと乗っていきたいと思う。 なお、子供には謎に五右衛門という命名がされている。

概要 なんとなく思うところがあり、WordPressで運用するメリットもなくなってきたので思い切ってHugoへ移行した。　やはり静的サイトになって軽くなるのが一番良いかなと思っている。 その分使い勝手はわるくなるかもしれないが、Markdown使えるしまぁよいかなと。 静的サイトにしておけば、最悪VPSをやめるもできると思うのでとりあえず満足。 ただ、唯一意味がわからなかったのがGitHub Actionsでデプロイしたときにhugo --minifyでUnable to locate config file or config directoryと出てしまう点だけよくわからず、最終的には hugo --minify --config hugo.toml で指定して回避してる。 これだけは謎い。

6月8日 10時〜12時 副業先のElastiCacheのアップデート対応と、SendGridの新しいアカウントでSenderAuthenticationの設定を追加。 本業でElastiCache関連は色々対応していたものもあり、余裕を持ってできたし、SendGridの認証は何度も何度もやってきた。なんなら前職でも前々職でも副業でもやってきたので流石に慣れた。 13時〜18時 カーシェアで借りた車で練馬と新宿のショールームに行って、キッチンを見たり玄関扉とかリビング用の扉を見るなどした。結構面白い。 あと、ショールームのお姉さんから、普段気にもしていなかったようなオプションの提案をされて、気づきを与えることで売上に貢献するという手法を学んだ。 18時〜21時 ジムに行って筋トレとランニングと風呂。ベンチプレスを真剣にやろうと思い、とりあえず40kgから始めてみることにした。ランニングは5km走った。 22時〜23時 Meetを使ってメンタリング。某プログラミングスクールの課題が難しいとのことで復習の相手として少しお高めの個別プランで対応。 いろいろな例えを使って説明するのはなかなか骨が折れるが、自分自身の振り返りにもなり、良い体験となっている。 6月9日 10時〜12時 MAZDAに行って書類の手続き。あとは納車待ちだ。楽しみ。 納車日についてはまだ連絡が無いので、いまかいまかと連絡待ちしている。 13時〜18時 電車で移動して、住宅の打ち合わせ。インテリアコーディネーターの人がいるとだいぶ話が早いしイメージもしやすくて助かる。 3色くらいで部屋のコーディネートをするとか、気になった1色が別の1色にも少し含まれていると印象が統一しやすいということを学んだ。 21時〜22時 DBのアップグレードメンテ、RDSのMySQL8移行を実施した。 スナップショットを取得して、取得したスナップショットからアップグレードができることは別のお客さんで実施済みだったのでスムーズに移行できたので良かった。 この土日は一日で3つくらいの大物を対応していった。 お陰で諸々の話がだいぶスムーズに進むことができたので、疲れることは疲れたものの、焦りのようなものが無くなったので終わってはいないものもあるがそれなりの達成感を得る事ができた。 とはいうものの、落ち着いたらどこかで何もしないDayとかは作りたい。

1/16 (火) 開催！Incident Response Meetup vol.1 @Sansanさんオフィス 前半はいつもの気になった点のメモです。後半が感想。 ハッシュタグは #障害対応 木村 誠明さん（「システム障害対応の教科書」著者） 障害対応→ダメージコントロールの世界 障害対応教育 暗黙知が殆んど、有識者はいつもいるわけではない 教育が難しい 障害対応の目的 システムを直すことではない ユーザ影響の回避、低減 インシデントコマンダーとは 必要な作業を各担当へ割り振り、実施指示を行い全体をリード 復旧要件、復旧仕様を決める システムの復旧が最善の道とは限らない ICと作業担当者は分ける 機械的な判断で人を巻き込む（人の判断をなるべくいれないことで心理的負荷を下げる） 情報をフローとストックにわける フローはタイムライン ストックは障害レベル、事象など WarRoom 障害対応の専用の部屋 物理、仮想は文化による 不慣れなツールは使えない インシデントコマンダーになるには インシデントコマンダーを育てる 作業担当としてオンコール参加、書記、窓口を経て Q&A 体系的に軍事が参考になることも 障害ランクの定義により、報告ラインを定義 ICをスイッチするはある（宣言する） あんどうさん @integrated1453（株式会社ユーザベース） グループ 1200名 エンジニア 70名 オンコールシフト、PagerDuty 記者等に話をすることもあるので、横文字は日本語にしている（ポストモーテム→障害撲滅委員会） BizメンバーのSOSはSlackからPagerDuty→運用当番 SRE Bookの信頼性の階層 monitoringが一番下 検知してからエンジニアのアサインに時間がかかると障害復旧までの時間がかかる 運用当番が手を動かそうとする

まず、最初に今年掲げた目標の振り返りをやっていく。 ダイエット: （1/1開始72.3kg, 目標65kg） 1月: 70.1kg(-2.2kg) 2月: 71.1kg(-1.2kg, 前月比+1.0kg) 3月: 68.4kg(-3.9kg, 前月比-2.7kg) 4月: 69.0kg(-3.3kg, 前月比+0.6kg) 5月: 68.9kg(-3.4kg, 前月比-0.1kg) 6月: 67.8kg(-4.5kg, 前月比-1.1kg) 7月: 67.5kg(-4.8kg, 前月比-0.3kg) 8月: 67.1kg（-5.2kg, 前月比-0.4kg） 9月: 65.4kg(-6.9kg, 前月比-1.7kg) 10月: 66.0kg（-6.3kg, 前月比+0.6kg） 11月: 66.5kg(-5.8kg, 前月比+0.5kg) 12月: 66.2kg(-6.1kg, 前月比-0.3kg) 達成率: 83% 65kgに到達したこともありつつ、65kg〜66kgの間を推移していた月だった。 惜しかったなぁという気持ちもありつつ、6〜7kg落とせたので上々だったということにしておく。 読書量年間50冊 1月: 4冊 2月: 3冊, 7 3月: 1冊, 8 4月: 3冊, 11 5月: 1冊, 12 6月: 2冊, 14 7月: 7冊, 21 8月: 2冊, 23 9月: 3冊, 26

概要 最近、Aurora2(MySQL5.7)だったクラスターをAurora3(MySQL8.0)にアップグレードしたところ、特定のクエリだけが失敗するという事象があった。 ClowdWatchLogsに出力していたerrorログには /tmp/xxx is full! と出力されていた。 Aurora2(MySQL5.7)の時代にはなかったことだったので、Aurora3(MySQL8.0)によるものであることはわかり、それが新しく採用されたTempTableストレージエンジンによるものであることがわかった。 TempTableストレージエンジンとはどういったものか、Aurora3の仕様もあわせて色々わかったので記録をしておこうと思います。 最初に結論 Aurora2からAurora3にアップグレードする際には temptable_max_ram と temptable_max_mmap の値を必ず確認して、必要に応じて調整したほうが良い。 TempTableストレージエンジンとは 詳細な説明は下記を参照してもらうとして、ざっくり説明すると内部一時テーブルを使うようなクエリを実行した場合に、MySQL5.7のときにつかっていたInnoDBテーブルではなくメモリを利用したストレージエンジンとなり、5.7のときよりも効率的にクエリを処理することができるようになったストレージエンジンのことを指す。 https://dev.mysql.com/doc/refman/8.0/ja/internal-temporary-tables.html TempTableストレージエンジンでは temptable_max_ram を上限としてオンメモリで処理されて、それを超えると、temptable_max_mmap を上限として、mmap()システムコールにより、ローカルストレージにファイルを作成して、仮想メモリにマッピングを行う。 ページサイズ単位（Linuxではデフォルト4KiB)でメモリ上にデータがロードされるので、InnoDBテーブルに変換される場合よりも、効率的（可変長）で高速に処理される。 では、temptable_max_mmap を超えたサイズのデータをクエリするような場合はどのような挙動になるか。 MySQL8.0の挙動 Aurora3に関わらず、MySQL8.0の仕様では、temptable_max_mmap を超えると、InnoDBテーブルに書き込むようになる。 つまり、遅くはなるけど処理は継続される。 Aurora3の挙動 Aurora3ではどうなるかというと、ライターとリーダーで挙動が異なる。 ライターはMySQL8のデフォルトの挙動と同じになるが、リーダーの場合は temptable_max_mmap の値を超えると /tmp/xxx is full!とエラーが出力されてクエリが失敗する。 temptable_max_ram と temptable_max_mmap はデフォルト1GiBなので、合計2GiBを超えるようなクエリは失敗して終了してしまう。 原因についてはAWSサポートにも確認してわかっているが、まずAuroraは共有ストレージを採用しており、 そして、リーダーインスタンスは共有ストレージを参照は可能だが、書き込みはできない。 内部一時テーブルを作成するのにあたり、ライターは問題にならないがリーダーインスタンスで、MySQL5.7のときは共有ストレージではなく、ローカルストレージにMyISAMとして書き込みを行う仕様だった。 リーダーインスタンスでは、オンディスク一時テーブルはローカルストレージを使用する MyISAM ストレージエンジンを使用します。これは、読み取り専用インスタンスでは Aurora クラスターボリュームにデータを保存できないためです。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.CompareMySQL57.html MySQL8.0.16以降、内部一時テーブルのストレージエンジンを指定していた internal_tmp_disk_storage_engine が廃止されて、デフォルト InnoDB となった。 Auroraでもこの仕様に則り、Aurora2では internal_tmp_disk_storage_engine が適用され、Aurora3では internal_tmp_mem_storage_engineが適用されるようになった。 パラメータグループをみても、Aurora2のときにあった internal_tmp_disk_storage_engine は Aurora3では見当たらず、かわりに internal_tmp_mem_storage_engine のみが存在する。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html internal_tmp_mem_storage_engine はメモリを使った内部一時テーブルの処理のみとなり、デフォルトが TempTable で、MEMORY にも変更は可能である。