概要 最近、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 にも変更は可能である。

概要 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 "

概要 最近、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;'>

AWS Summit 2023へ参加してきたのでそのレポートです。 本日はこちら pic.twitter.com/VKhneyAGUl — Inamuu🏕 (@kzm0211) April 21, 2023 今年は品川ではなく、幕張メッセでの開催となった。 最初の基調講演はまるでフェスだった。 AWSのVPoE、ANAとPayPayカードの事例を聴くなどした。 また、各社のスポンサーブースがあり、いろいろな話を聴くことができた。 Hashicorp社の箸（Hashi）。洒落が効いてて好き。 巡回ロボが巡回していた。 いろんな会社が書いてた。弊社もスポンサーとかなれたらいいなぁ。 DeepLacerのレースやってた。 結構コースアウトしていて、なかなか難しいということを実感した。 感想 数年ぶりのオフライン開催ということで、かなりの盛り上がりだった。 私は会社の人と行ったが、途中で元副業先のCTOとばったり会ったりして、業界の狭さを感じた。 パイプ椅子で30分〜1時間聴くのは大変だが、クッションを無料配布してくれたのはとてもありがたく、おかげで概ね耐えられた。 今まではオフライン開催というのはかなり抵抗があったかと思うのだが、今回のイベントはあまりそういったしがらみのようなものは無く、各々が判断をして普通に参加出来ていた様子。 今後もこういったイベントは増えていくと思うし、盛り上がっていければと願う。 参加した皆様と運営の皆様はお疲れ様でした。 <p style='padding: 5px;'>

概要 2月の振り返り記事にも書いたのだが、2月はRDS関連のメンテ対応をしていたのもあり、RDSは深く勉強し直す必要があると思っていた。 そこで、手っ取り早く体系だって勉强するのに、DBSは丁度良かったので勉強していた。 ただ、メンテ前はプレッシャーだなぁと思って、試験日を何度か延期していて、メンテも終わったし、心に余裕が出てきたので受けることにした。 結果 3/5にうけてきて合格した。 合格点750点に対して798点なので決して良いという点では無いものの、結果のコンピテンシーのバランスは悪くなさそうだった。 勉強方法 まず、下記を読んだ。1回ほど、結構流し読み的な感じ。 それで、巻末の問題は1回やって、間違った問題だけ2回目やった。 <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/51c3jr0owxS._AC_AC_SR250,250_.jpg?w=750&#038;ssl=1" alt="要点整理から攻略する『AWS認定 データベース-専門知識』 (Compass Booksシリーズ)" data-recalc-dims="1" /> </div> <div class="naaa-product-title naaa-product-title-h"> 要点整理から攻略する『AWS認定 データベース-専門知識』 (Compass Booksシリーズ) </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="6686b5310c019"> <input type="radio" class="naaa-input-star" name="6686b5310c019" value="10" /><label class="naaa-full naaa-label-star" title="4.4 de 5"></label><input type="radio" class="naaa-input-star" name="6686b5310c019" value="9" checked='checked' /><label class="naaa-half naaa-label-star" title="4.

概要 ECS Taskを定期実行したい要件があり、それをただ実行するならEventBridgeからcronのように呼び出すことになる。 しかし、ECS Taskそのものにはリトライ処理が無く、EventBridgeだけだと複数のジョブの処理などに限界があったので、今回はStepFunctionsを検証した。その辺りをざっくりまとめる。 なお、今回はAWSコンソールの作業のみでIaCは検証のため無し。 EventBridgeのリトライ処理について EventBridgeでもリトライ処理はできるが、意図したエラーハンドリングが出来ない可能性がある。 例えば、ECS Taskでアプリが例外を吐いてもリトライされない。 おそらくECS Taskそのものが起動しないなどのエラーだけをリトライ処理できると思われるので、何をトリガーにリトライ処理をしたいかは確認しておく必要がある。 アプリのエラーについては素直にStepFunctionsを使うと良さそう。 下記の記事で詳しく記載されていた。 ちなみに自分の場合、FargateのECS Taskでも同様だったので、EventBridge自体の制約だと思われる。 [AWS] EventBridge Rules による ECS Scheduled Task はエラー時リトライできない 要件 自分で作成したコンテナイメージを使いたい コンテナイメージにコマンドを上書きして、実行させたい（イメージを共通化） リトライ処理したい 定期実行したい コンテナイメージ 今回はシンプルにこんなコードを用意した。 コードの良し悪しはさておき、引数を取って、各関数を実行させられるかの確認。 <?php function main(){ global $argc; global $argv; print("start: run php test function\n"); if ($argc != 2){ print("info: please set argument\n"); return; } $argval = $argv[1]; print($argval()); } function example_1(){ print("result: exmaple 1\n"); } function example_2(){ print("

概要 最近話題になっていたAWSのVPC Resource mapを使ってみたら便利だったのでその記録。 VPC Resource mapとは 詳細は下記リンクにあるが、AWSコンソールで使用ができるシンプルなページで、VPCのアーキテクチャレイアウトがすぐに分かるような、ルーティングがビジュアライズされた機能のことのようだ。 Today we are announcing Amazon Virtual Private Cloud (Amazon VPC) resource map, a new feature that simplifies the VPC creation experience in the AWS Management Console. This feature displays your existing VPC resources and their routing visually on a single page, allowing you to quickly understand the architectural layout of the VPC. https://aws.amazon.com/jp/blogs/aws/new-visualize-your-vpc-resources-from-amazon-vpc-creation-experience/ プライベートアカウントで確認 実際に自分がプライベートで契約しているAWSのアカウントで確認してみた。 プライベートなアカウントではコスト面からNAT Gatewayは無いのでシンプルな構成になっている。 public subnetが 1aと1cに存在しており、public-route-table-igwのルートテーブルにより、igw(Internet Gateway)経由でインターネットにつながっていることがひと目で分かる。

概要 仕事をしていると、歴史のあるシェルスクリプトがEC2で動いていたりすることがある。 そういったスクリプトをなにかしらのスクリプト言語で書き換えるのもやぶさかではないのだが、数が多いと諦めの気持ちが湧き出てくる。 そこで、シェルスクリプトのままでもLambdaにデプロイしてバッチ的に動かして、サクッと移行できたりしないかなという思いが出てきた。 そこで、Lambdaのデプロイツールにlambrollを検証してみることにした。 インストール 手元がMacOSなのでbrewでインストール。 $ brew install fujiwara/tap/lambroll $ lambroll versions 2023/01/18 23:14:53 [info] lambroll v0.14.1 with function.json 2023/01/18 23:14:53 [error] failed to load function: open function.json: no such file or directory 使ってみる とりあえす空ディレクトリで下記を実行する $ lambroll init --function-name=testLambrollFunction --profile XXXXX 2023/01/18 23:22:05 [info] lambroll v0.14.1 with function.json 2023/01/18 23:22:05 [info] function testLambrollFunction is not found 2023/01/18 23:22:06 [info] creating .lambdaignore 2023/01/18 23:22:06 [info] creating function.json 2023/01/18 23:22:06 [info] completed 出来上がったJSONを見ると、デフォルトでは nodejs14.

いわゆるクラウドと言っても、実際にはAWSも物理的に物が動いている世界で、どのようにクラウドの世界が作られているかをまとめてみようと思います。 ただし、基本的にはAWSの物理的な情報は非公開のものが多いので、情報の出どころが定かではない場合が多いため、参考程度にとどめていただけますと幸いです。 サーバー台数 https://www.publickey1.jp/blog/12/amazon_15.html 早速2012年の古い記事ではありますが、、、 Amazonクラウド全体の物理サーバは45万4400台、7100ラックではないかと書いています。また、東京リージョンは物理サーバが2万台と推測しています。 という記載があります。10年も前の記事ですでに2万台とのことですので、2022年現在では大阪リージョンもありますから、日本だけでも今ではもっと物理サーバーが存在するといえるでしょう。 また、AWSが提供するEC2は仮想サーバーと呼ばれるもので、物理サーバーの上に複数台稼働をいたします。 つまり、実際には 物理サーバー x 仮想サーバー 台数が稼働しています。 少し前にAmazonのプライムデーで使用されたサーバー台数がAWSのエンジニアから公開されていますが、40万台あまりのサーバーが使われたようです。（物理的にではなく仮想だと思われます。） https://www.itmedia.co.jp/news/articles/1908/20/news088.html Amazon ECインスタンスにより、Prime Day開始時に37万2000台相当のサーバを起動。ピーク時には42万6000台相当に Amazon EBSによる63ペタバイトのブロックストレージと、1日あたり2兆1000億回のアクセス、1日あたり185ペタバイトのデータ転送 Amazon DynamoDBに対して合計7兆1100億回のAPIコール。ピーク時には1秒あたり4540万回のリクエストを処理 Amazon Auroraによる1900個のデータベースインスタンスと609テラバイトのデータベース。1480億回のトランザクション、 これだけで途方も無い数字です。 私が以前勤めていた会社でもサーバーを管理していましたが、それでも物理、仮想を含めて1000台あまりだったと記憶しています。 サーバー仕様 https://www.geekwire.com/2017/amazon-web-services-secret-weapon-custom-made-hardware-network/ AWS’s more recent custom storage servers hold 11 petabytes (one million GB) of data on 1,100 disks contained in a single standard-size 42U rack, up from the 8.8 PB in the 880-disk model that Hamilton showed これはストレージやルーターの話ではありますが、彼らがハードウェアレベルでサーバー、およびチップセットをカスタマイズしていることがわかります。 国内のサービスでも、このようにハードウェアに造詣の深いエンジニアがいるところでは、自作サーバーで提供するという話もちらほら聞いたりします。（最近ではかなり減ってきた気がしますが）

AWS SOA AWS SOAを受検したのは、先週の話です。 先週の日曜日にAWS SOAを受検してきました。 感想としては、スコアに反して結構難しかったという印象です。 運用者向けの問題が多く、OraganizationやCFnのトラブルシュート、AWS SSOやCost Explorerあたりがよく出題されたと記憶しています。 今回は koiwaclub のみで、挑戦しました。 これまでに、CLF/SAA/DVAを取得してきましたので、一部は補完できますが、不足していた部分もありますし、個人的には一番選択肢が謎な問題も多かったなと思っています。 その辺は追々理解度を深めて行く必要があるだろうなと感じています。 とりあえず、9月までにCLFとAssociateシリーズは取り終えたかったので、4月から3ヶ月強で取得できたのは良かったです。 上記を埋めていきたい所存。 電工二種　技能試験 こちらは先日の土曜日に、五反田TOCビルで受験してきました。 私がいったところでは、おそらく数百人が参加し、事前に公表された13問のうち出題される1つを実際に組み立てていきました。 候補問題 試験会場の五反田TOCビルは五反田駅から離れているという点が難点ですが、直線で向かえるのが良い点です。 他にも都内では渋谷や流通センターなどで試験が行われたようで、全国でも開催されていますから、それこそ数千人から数万人規模なのではないかと推測されます。 さて、試験は11:30分開始ですが、会場には10:50に入るように記載がありました。 それを見落としてしまうと、受験ができません。 10:55以降を入室禁止としますとアナウンスされていましたが、実際にはもう少し過ぎても五反田は受け入れていたように見えます。 ※隣の席の人が10:55過ぎても来なかったので、机を広く使えるぞーと思ったら、11:00頃に普通に来てて、残念でした。 会場ごとにここの判断が異なったようなので、人も多いですし、トイレとかも考えたら10:50から30分くらいは早く到着するようにしたほうが良いのは間違いないです。 その後、小さな箱に試験キットが含まれていて、これはアウトレットボックスは無いぞー！！と心の中で歓喜していたら、普通にアウトレットボックスが入っていて衝撃でした。 ※五反田TOCはNo.11でした。 とりあえず合否はまだ先で、いくつか不安な箇所があるので、一ヶ月くらいは不安を抱えることになりますが、筆記が通っているので一応落ちても下期に受け直せますのでしばらくは悶々としておきます。 第二種電気工事士の技能試験が終わった。 皆さんお疲れ様でした。 私はミスがあってやり直したりしたので時間ギリギリでした。 五反田TOCはNo.11。 とりあえず完成＆見直しまでしたが、不安は残りつつ結果待ち。 ※写真はTOCビル入口でアプリが落ちてデスクトップになってるの図#電工二種 pic.twitter.com/FQvCXkFz4z — Inamuu (@kzm0211) July 17, 2021 まとめ とにかくこの3ヶ月はAWSと電工二種で疲れました。 まだ結果も出ていないですが、一区切りついたので、また別の資格を狙っていきます。 今年も相変わらずコロナで巣ごもり状態なので、資格取得という形でインプットを増やしていきます。 いずれTOEICとかもやっていきたい。 <p style='padding: 5px;'>