Popular posts
-
納車 先週の日曜日、ついに待ちにまった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 にも変更は可能である。
Less