概要 MySQLのLIMITを使ったクエリでは、ORDER BYの結果が変わるというものがある。 https://dev.mysql.com/doc/refman/8.0/ja/limit-optimization.html それについて手元で検証した。 使用する環境 MySQL8.0のDocker。ただし、MySQL5.7でも同様の事象が確認できると思われる。 FROM --platform=linux/x86_64 mysql:8-debian ENV LANG ja_JP.UTF-8 ENV LANGUAGE ja_JP:ja ENV LC_ALL ja_JP.UTF-8 ENV MYSQL_ALLOW_EMPTY_PASSWORD=yes RUN useradd mysqld COPY mysqld_charset.cnf /etc/mysql/conf.d/mysqld_charset.cnf ADD world-db.tar.gz /docker-entrypoint-initdb.d/ CMD ["mysqld"] テストデータ 下記のようなテストデータを作成した。 mysql> select * from item order by created_at limit 20; +----+------+---------------------+ | id | name | created_at | +----+------+---------------------+ | 68 | 0 | 2023-12-20 18:00:00 | | 64 | 0 | 2023-12-20 18:00:00 | | 65 | 0 | 2023-12-20 18:00:00 | | 66 | 0 | 2023-12-20 18:00:00 | | 67 | 0 | 2023-12-20 18:00:00 | | 60 | 0 | 2023-12-20 19:00:00 | | 63 | 0 | 2023-12-20 19:00:00 | | 62 | 0 | 2023-12-20 19:00:00 | | 61 | 0 | 2023-12-20 19:00:00 | | 59 | 0 | 2023-12-20 19:00:00 | | 52 | 0 | 2023-12-20 20:00:00 | | 46 | 0 | 2023-12-20 20:00:00 | | 44 | 0 | 2023-12-20 20:00:00 | | 47 | 0 | 2023-12-20 20:00:00 | | 53 | 0 | 2023-12-20 20:00:00 | | 43 | 0 | 2023-12-20 20:00:00 | | 45 | 0 | 2023-12-20 20:00:00 | | 51 | 0 | 2023-12-20 20:00:00 | | 49 | 0 | 2023-12-20 20:00:00 | | 33 | 0 | 2023-12-20 20:00:00 | +----+------+---------------------+ 20 rows in set (0.

はじめに これは株式会社マクアケのアドベントカレンダー2023の17日目の記事です。 SREチームに所属する稲村です。 最近は久しぶりにランニングを再開して、よく走るようになったものの体力の衰えを実感しているもうすぐ四十路のおじさんです。 さて、今回はスクラム関連の記事です。 スクラムについては、私は完全なスクラム開発自体はほぼ未経験で、前職でもスクラム風な一部を省略する形でスクラムを実践してきました。 通常、スクラムのプラクティスを省略するのはアンチパターンと言われてスクラムバットと言うそうですが、まずはやってみる精神で進めていた状況でした。 スクラムについては、過去に下記の書籍を読んではいました。 <div class="naaa-product naaa-product-h"> <div class="naaa-product-thumb"> <img decoding="async" class="naaa-product-img-h" src="https://i0.wp.com/m.media-amazon.com/images/I/51YUJzbRtwL._AC_AC_SR250,250_.jpg?w=750&#038;ssl=1" alt="いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法 「いちばんやさしい教本」シリーズ" data-recalc-dims="1" /> </div> <div class="naaa-product-title naaa-product-title-h"> いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法 「いちばんやさしい教本」シリーズ </div> <div class="naaa-product-price"> <div class="naaa-product-price-h"> </div> </div> <div> <div class="naaa-product-action"> <div class="naaa-product-button naaa-product-button-border"> 見てみる </div> </div> </div> <div class="naaa-rating-and-review-h"> <span class="naaa-product-rating"> <fieldset class="naaa-rating" id="6686b532c1057"> <input type="radio" class="naaa-input-star" name="6686b532c1057" value="10" /><label class="naaa-full naaa-label-star" title="3.9 de 5"></label><input type="radio" class="naaa-input-star" name="6686b532c1057" value="9" /><label class="naaa-half naaa-label-star" title="3.

ダイエット: （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) 達成率: 79% 読書量年間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 10月: 3冊, 29 11月: 1冊, 30

概要 久しぶりにツーリング仲間の皆さんと犬吠埼までツーリングに行ってきた。 最初に酒々井SAで集合になったんだけど、高速とにかく混んでいてびっくりした。 皆さんと合流して、自分の大陸製のFODSPORTSというインカムとなんとか繋げて初めて話ながら犬吠埼にあるホテルに向かった。 海風がとにかく強くて結構たいへんだったけど、夕焼けがとてもきれいで、また風力発電の風車が幻想的だった。 ※写真が撮れなかったので引用です。 https://cosmo.eco-power.co.jp/wind_power/choshi/ 宿泊は別邸海と森という所で、久しぶりに少しお高めのホテルに泊まることになった。周りはみなさん役職付きだから…。 夜も朝も懐石料理が出てまさに舌鼓を打った。 ホテルの時計にあったとおり06:15くらいに朝焼けを見ることができた。テラスはオーシャンビューで、お風呂付きだったのでこっそり一人で朝焼けを満喫しながらお風呂に入って極楽だった。 距離としては短めだったけど、全然知らない土地に普段あまり喋ったことのない人達と行くツーリングはなかなか楽しかった。 また、ホテルもとても良かったし、一年に一回くらいはこうやって贅沢するのはありだなぁと思ったツーリングでした。 <p style='padding: 5px;'>

ダイエット: （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） 達成率: 86% 読書量年間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 10月: 3冊, 29 達成率: 58% ブログを週一（1年は52週間なので52記事）、うち技術的アウトプットブログを毎月2つ（24記事）以上書く 1月: 6記事 2月: 3記事, 9

概要 Auroraクラスターの検証をしていて、とある理由で停止しておきたいけど、しばらくは削除したくないというときがある。 Auroraは自動的に停止7日後に自動で起動してきてしまう。 そこで、なんとかできないか色々見てたらEventBridgeと会社の同僚氏から提案されたSSMオートメーションの組み合わせが一番良かったので記録しておきます。 構成 Auroraクラスター EventBridgeルール SSMオートメーション Terraform まず、必要なIAMを作成する。 対象のクラスターに対してのみ、参照と停止の権限を付与する。 resource "aws_iam_role" "stop_db_clusters" { name = "automation-stop-db-clusters" assume_role_policy = data.aws_iam_policy_document.stop_db_clusters.json inline_policy { name = "automation-stop-db-clusters" policy = jsonencode( { "Version" : "2012-10-17", "Statement" : [ { "Sid" : "rds", "Effect" : "Allow", "Action" : [ "rds:StopDBCluster", "rds:DescribeDBClusters" ], "Resource" : [ "arn:aws:rds:ap-northeast-1:123456789:cluster:example-db1", ] }, { "Sid" : "ssm", "Effect" : "Allow", "Action" : "ssm:*", "Resource" : "*" } ] } ) } } data "

ダイエット: （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) 達成率: 94% インフルになったのもあって、5日くらいおかゆとかスープとかにしていたらめちゃくちゃに体重が下がった。 もっと体重減っていたのだけど、ご飯の量を戻してきたら今の体重まで戻ってきた。 一旦の目標まであと少し。 読書量年間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 達成率: 52% やはり図書館に行くと読書数が増える。とは言え、目標数には全然及ばないので少し増やしたいところ。 ブログを週一（1年は52週間なので52記事）、うち技術的アウトプットブログを毎月2つ（24記事）以上書く 1月: 6記事 2月: 3記事, 9

2年前に前職にいるときに Slack認定管理者(Slack Certified Admin) なるものを取得したのだけど、　Slack認定管理者試験を受検した それが、今月末で切れるとの通知を受け取った。 とはいえ今やEnterprizeGridも使っていないし（当時は使っていたのもあり）、DLPだったりSCIMなんてのはもちろん、Slackの管理者ですらないので更新しないつもりだった。 が、Slackから受け取ったメールを見たら、Maintenance Lessonを受けて簡単なQuiz（何度間違えてもOK）を合格したら更新するよとあったので、ほんまかいなと思って受けてみた。 Maintenance Lessonは1時間くらいのもので、以前やったウェブページによるレッスンで座学を受ける。 PrivateチャンネルをPublicチャンネルに変更できるとか、チャンネルマネージャーとかが新しい情報がありつつ、ささっと流して受験してみた。 レッスン1時間に対して10問だけという問題数で、まさかの6/10！ 前回も合格点ギリギリだったので、ホントなんとも言えない。 まぁでも試験問題が今回は全部英語だったのでしょうがない（？） ちゃんと1年更新されていたので良しとします。 <p style='padding: 5px;'>

ダイエット: （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） 達成率: 71% 66kg台を前後していたけどちょっと気が抜けてしまい、67kg止まり。惜しい。 読書量年間50冊 1月: 4冊 2月: 3冊, 7 3月: 1冊, 8 4月: 3冊, 11 5月: 1冊, 12 6月: 2冊, 14 7月: 7冊, 21 8月: 2冊, 23 達成率: 46% 7月はせっかく勢いがあったのに勢いを落としたのはもったいないことをした。 読みかけの本が数冊（いや、数十冊）あるので、読み進めていきたい。 ブログを週一（1年は52週間なので52記事）、うち技術的アウトプットブログを毎月2つ（24記事）以上書く 1月: 6記事 2月: 3記事, 9 3月: 6記事, 15 4月: 3記事, 18 5月: 3記事, 21

概要 最近、Auroraのインスタンスサイズを下げようと検討しているインスタンスがあったので、購入済みのリザーブドインスタンスから試算することになった。 そこで、Aurora、およびRDSのリザーブドインスタンスの知識として、知らなかったことがいくつかあったのでその記録。 結論 RDSには柔軟性の考え方がある（Auroraも該当する） インスタンスファミリーが同じ場合に適用される 柔軟性は小さいインスタンスクラスのインスタンスから適用される RDSには柔軟性の考え方がある。 RDSのリザーブドインスタンスを購入する際の基本知識として、柔軟性の考え方がある。 https://aws.amazon.com/jp/about-aws/whats-new/2017/10/amazon-rds-reserved-instances-offer-instance-size-flexibility/ 新規および既存の RDS RI すべてにおいて、同じデータベースエンジンを使用する DB インスタンスファミリーの任意のサイズで使用量に応じた割引が自動的に適用されます。RI ディスカウントの割引はまた、同じデータベースエンジンおよび DB インスタンスファミリーのシングル AZ とマルチ AZ の両方の設定で使用量に応じて適用されます。 これがどういうことか説明する前に、RDSのインスタンスにはクラスごとに正規化係数というのが定められている。 2017年10月以降、RDSのインスタンスサイズが異なる場合でも、購入しているリザーブドインスタンスが適用されるというもの。 公式サイトの例でみると、もしt2.mediumのリザーブドインスタンスを購入している場合に、t2.mediumではなくて、t2.smallが2台でもリザーブドインスタンスが適用されるということである。 この場合、シングルAZだったとして、t2.mediumの正規化係数は2であり、t2.smallの正規化係数は1であり、それが2台なので購入済みのリザーブドインスタンスの正規化係数と同じになるので、追加でオンデマンド費用は発生しないこととなる。 これは、リザーブドインスタンスを最初に1つ購入したものの、あとからインスタンスサイズを下げて2台に冗長化するといった場合でもリザーブドインスタンスが無駄にならないようになっている。 インスタンスファミリーが同じ場合に適用される これは同じインスタンスファミリーにしか正規化係数は合算されないので、t2.smallのリザーブドインスタンスがあっても、t4g.smallには適用されず、そのままオンデマンド費用となるということ。 インスタンスファミリーに関しては、リザーブドインスタンス購入後は諦めて同じものを使い続けたほうが良さそうだ。 柔軟性は小さいインスタンスクラスのインスタンスから適用される 最後のこれが中々理解が難しかった。 例えば、下記場合にどうなるか。 例: 購入済みのリザーブドインスタンスは以下となる(いずれもシングルAZで同一インスタンスファミリー)。 2xlarge x 1 正規化係数は16である。 次の場合に、下記インスタンスを所有するとリザーブドインスタンスの適用はどのようになるか。 2xlarge x 1 xlarge x 1 まず、2xlargeのリザーブドインスタンス16から、xlargeの1台分8が引かれて残り8となる。 次に、2xlargeのリザーブドインスタンス8から、2xlargeの1台分16のうち8が引かれて0となる。 残りの2xlargeの正規化係数8については　2xlargeのオンデマンド費用 として請求される。xlargeの1台のオンデマンド費用ではないところがミソである。 まとめ 試算しているときに請求書をみていたら、なぜか追加購入していないはずの一番でかいインスタンスサイズのオンデマンド費用が発生していて疑問に思って調べてわかった。 特に最後のところは、AWSサポートにも確認して、認識に違いが無いことがわかった。 期初にリザーブドインスタンスをぴったりで購入したあとに、追加で低いインスタンスサイズのRDSを購入したからそれだけオンデマンドになるだろうと思ったら、そうじゃないので注意が必要。 また、柔軟性を知らないと、リザーブドインスタンスの期限が切れるギリギリまで待たないと、インスタンスサイズが下げられない!と勘違いをしてしまうかもだが、正規化係数によっては損をしない可能性がある。 これからインスタンスサイズを下げたいな〜と思ってたり、RDSの請求書に追加購入していないのにオンデマンド費用が発生していたら、このあたりを確認すると良さそうです。 <p style='padding: 5px;'>