AWS re:Invent 2022 にて RDS の Blue/Green が発表されたことを受けて、この辺の具体的な運用をどのように改善できるのか考えていきます。 たいした内容ではないですが、丁寧に最適化して慣れれば、それなりに強い効果を発揮できそうな感じはあります。 ALTER TABLE の辛み まず復習からですが、RDS に Blue/Green が実装されるほど辛い運用はなんだったかというと、重い ALTER TABLE にあります。 ALTER には色々あるのでアレですが大雑把に言うと、容量や行数が大きいテーブルに対して実行すると、数時間単位～の処理時間がかかることが多く、しかもパッと見で進捗を把握できないという問題を抱えていました。それに対して色んな対策を取っていたと思います。例えば…… Handler_write SHOW GLOBAL STATUS LIKE ‘Hand

という感じで、特別に学歴が高いとか、小さい頃からコンピューターに触れてきたとかなくて、強いて言うなら３歳からゲーマーだったというくらいです。あとわざわざ北海道を出たのは、雪と寒いのが嫌いだからです。 振り返ってみると、入社からたった４ヶ月程度で退学を決心してて狂気ですね。決心した後は、まず社長に相談して、当時のバイト代だと生きていけないので、もう１つバイトしようと思います～って話したら、即断で社員になればいいじゃん。って流れになり、当時は役員とバイトだけだったため、めでたく正社員第一号になりました。 んで親に電話して、やりたいことが見つかったことと、今辞めれば後期の学費かからないよ！とか意味不明な説得したりして、なんとか了承を得ました。友達には全員に勿体ないと言われましたが、逆にこれが正着なんだと俄然やる気でました。 今現在、当時の生き残りは俺と社長だけですが、要所で即断即決できるってのは

Redis互換で25倍高速とする「Dragonfly」が登場。2022年の最新技術でインメモリデータストアを実装 Redisやmemcachedに代表されるインメモリデータストアは、高速なデータアクセスを要求される場面で使われています。 このインメモリデータストアを2022年の最新技術を用いて設計、実装することで、Redis/memcached互換を実現しつつRedisの25倍高速とする「Dragonfly」が登場しています（開発元のアナウンス、GitHub）。 Redisやmemcachedが登場した十数年前と比べて、現在ではCPUのマルチコア化やI/Oの高速化、メモリの大容量化など、ハードウェア技術が大きく進化しています。 これらを最大限活用する設計と実装を取り入れることでRedisやmemcachedよりも大幅な高速化と高効率化を目指したのがDragonflyです。 採用した主な技術

AWS News Blog Amazon Aurora Serverless v2 is Generally Available: Instant Scaling for Demanding Workloads Today we are very excited to announce that Amazon Aurora Serverless v2 is generally available for both Aurora PostgreSQL and MySQL. Aurora Serverless is an on-demand, auto-scaling configuration for Amazon Aurora that allows your database to scale capacity up or down based on your application’s

前回の記事でイィ感じの燃え方してイラつきはしたけど、ちゃんと調べず適当に公開したのはマズかったし、どっちみちそれまで理解が浅かったのは事実で認識してたので、それはもういいんです。 それよりもなんで、昨今はこんなにクソコメが蔓延るようになったんやろって考えてみたくなりました。エンジニアに限らず、ジャンル問わず社会的な話でもあるのですが。 社会的な風潮 要は『叩く』という行為が流行を通り越して当然になってる風潮ですね。 エンジニア関連でも、昔から技術系掲示板では、そんなことも知らんのかい！とツンツンしながらも教えてあげる文化みたいなものはありましたが、そういう『限定的な場』に自分から踏み入れない限りは、エンジニア同士の交流の多くは所属や個人サイトが判明している人だったりして、誤りや改善点があれば、スマートに指摘して、素直に受け入れる、ような流れが多かったように思います。 SNSが流行りだしてか

全然たいした話ではないのですが、へーって思ったので記録しておきます。 ALB にて外部からの不正アクセスを塞いだ話になります。 はじめに注意 ※追記３ この記事は、知識不足な状態で始まり、知識不足なまま初出した未熟な内容であり、外部の助力によりそれが解決に向かう、という流れになっています。 調査環境がAWSだったために、タイトルがこうなっていますが、実際はALB+ACM単独の問題ではなく、SSL/TLS としての仕様の話になっている、 ということを念頭において、読んでいただければと思います。 ※追記３ここまで 構成と問題点 手動で作成された ALB → EC2 環境があって、ワイルドカードなACM を使って 0.0.0.0:443 のみ開いており、EC2 は Global からのアクセスは遮断してありました。 にも関わらず、不正系なHostヘッダでアクセスされた形跡があり、コイツどこから来

元々は最近、息子と行動を共にしていて感じたことを下書きしておいた話でしたが、 「強いエンジニアは結局休日に勉強してるじゃん」って思うけど – spice picks を見て、鉄を熱いうちに打つことにしました。 他人と比べることなかれ 基本的な考え方としては、これ。 なんだけど、その趣味にエンジニアリングを含む場合、その人との時間格差は開く一方になるのは事実で、それはどうしょーもないので、自分なりのベスト、ベターを尽くせれば別に他人と比較しなくてよくねって思ふ — 外道父 | Noko (@GedowFather) March 28, 2022 エンジニアとして大成したいとか、年収1500万円欲しいとか、そういう目標があるなら別だけど、野球や将棋みたいにプロって概念があるわけでもないし、自分や家族に十分な収入を得るところまでは頑張る必要はあっても、その先は人それぞれでしかない話だと思います。

吉光使いとして鉄拳７にまず思うこと。 それは圧倒的にコスチューム、カスタマイズなのであります。 宇宙忍者とは そもそも『宇宙忍者』というコンセプトが意味不明ではあるんだけど、エイリアン要素と和風の洗練されたMIXが魅力だと思っていて、 主に骸骨顔・甲冑をチャームポイントに、日本刀を添えて和風テイストに仕上げた上で、宇宙スパイスを少々加えたところが最＆高だったわけです。 他に『からくり忍者』という異名もあり、『義賊』であるので、忍者という和をベースとして格好良くいて欲しい。というのが個人的な嗜好でした。 軟体動物 そんな吉光さん、１０年ぶりに再会してみると、『イカ』になってました。あのキュートなお顔はツンツルテンに…… 他に忍者が増えたから宇宙要素を強くしたように感じるけど、正直これは性能が吉光なだけで吉光ではないナニカや。今作のが気に入っている人には申し訳ないけど、こればっかりはしゃーない

鉄拳SNS『zexi』は、鉄拳プレイヤーのコミュニケーションの場として活発に利用され、2022年3月11日をもって閉鎖しました。 本業の経験を生かしてサーバー管理を担っていた立場として、軽く振り返ってみたいと思います。 はじまり 鉄拳界で最も知名度の高い人物の一人であろう、ご存知 天帝ゼクス が運営を担当していたのですが、彼と知り合って、どのような流れでSNSのサーバー管理をする流れになったのかは忘れました。多分、新宿JoyBoxの帰りにウチに泊まり鉄拳にきたりしてる間に自然と請け負ったんだと思います。 zechs が創る mixi みたいなSNS zexi は、発音が同じ結婚情報ゼクシィとも相まって、強力無比な名付けでした。あなたが神か。 サーバー構築 SNS構築に採用するのは MyNets ということで、私の当時の主要技術である PHP + MySQL であり、構築自体はそう難しいこと

はじめまして。またはお久しぶりです。 格闘ゲーム『鉄拳』の、古き吉光使い【Noko】です。 本業と混ぜるな危険だと思い、新たにブログを作ってみた次第です。 はじめに 2022年3月11日を最終日として、鉄拳SNS『zexi』が幕を閉じました。 データに未練はないですが、アレがなくなることで多少なりともインターネットに存在していた、鉄拳の思い出が失われるなーと思い、新たに記す場を設けてみました。 誰のためというワケでもなく、ただの自身の記録であり、ついでに子孫に真面目なゲーマーであったことが少しでも伝わればいいなと思いました、そんなところです。 元々攻略とかしないタチなので、くだらない駄弁り場の予定ですし、多分あんまり更新もしないですが、ボチボチよろしくお願いします。 使用キャラクター 吉光 プレイヤー名 【Noko】 鉄拳５DRまでは【漢の子】でしたが、長いので鉄拳６からは【のこ】にしまし

Amazon RDS MySQL/PostgreSQLのトランザクション性能が2倍に、可用性とスケーラビリティも高める新「マルチAZ配置オプション」登場 Amazon Web Servicesは、Amazon RDSのトランザクションの処理速度を最大で2倍にし、3台のクラスタ構成で可用性を高め、リードのスケーラビリティも向上する、新たな「Multi-AZ Deployment Option」（マルチAZ配置オプション）を発表しました。 New AWS News post by @sebsto: New Amazon RDS for MySQL & PostgreSQL Multi-AZ Deployment Option: Improved Write Performance & Faster Failoverhttps://t.co/sffr5boYlU — AWS Blogs (@AW

負荷試験＃開始と目的 の続きで、最初から目標を大きくしすぎず、アプリケーションと目的をなんとなく理解して、とりあえず始めていきましょうというところです。 どのようなデータを採取し整理すれば、ゴールに向かっていきやすいのか、を考えていきます。 条件と結果の記録 負荷試験には多くの関連項目があります。項目１つの記録や考察が抜けていただけで、最初からやり直し、ということも普通にあります。 最初から完璧な試験はなく、進行したことで判明する要素もあるので、最初から最後まで項目を決めつけて記録することは非常に危うく、常に今現在の試験が正しいのか、設定は最適なのかを疑う姿勢が必要です。 また、途中で項目数が変動する可能性があるということは、それまでの記録が一瞬にしてゴミに変わる可能性が常にある、ということなのですが、例えゴミだとしてもそれがゴミである証拠は必要ですし、それがなければゴミである確認のための

ヨッピー氏の 育児の現場で父親が透明化する現象について を受けて、脳裏が熱くなって何かを書き残したくなっちゃいました。育児がんばったしね！！ 育児の過去と現在の潮流があって、まさに次の世代ではどうなるかってところで、社会的な意識のアップデートのためにも、多くの意見や経験が共有されるとよいと思います。 父親の透明化の体感 議題となっていた透明化については、私自身はそれほど感じませんでした。 ゼロ歳からずっと育児して、こう言われて思い起こすと、若干そういう事象はあったかもだけど、ほぼ気にならなかったな。保育園や病院も良いバランスの対応だったし、父親も良く見かけたし、地域性が強く出る部分なのかもね…… https://t.co/jx3iCwaAov — 外道父／げどちー (@GedowFather) February 9, 2022 私は保育園は送り迎えを両方していたし、他の家も半分とまではいか

子を持ち育つと必ずやってくる関わりに、古の組織PTAがあります。 今回、そのうちの軽めの役割を担当した際に、作業を改善した内容の記録をしつつの雑談です。 PTAの現状 PTA – Wikipedia や各学校のPTA概要を見るとわかるのですが、Parent-Teacher Association とは名ばかりで、先生はあまり関わらず、一部の親たちによる半強制的な慣習的活動になっているのが多くの現状です。 在学中に１回は何かの役割を受けないといけないとか、年に数回の持ち回りの役目があるとか、そういうほぼ強制的な仕組みが批難の理由だったりするのですが── 活動内容によってはそうとも言い切れないのが面白いところ。 例えば運動会当日の準備と片づけは、要請されればパッと集まって済ませれば先生の負担が減るからやればいいし、登下校の旗振りはウチはシルバー人材の方が担当しているけど、見てると自分も歳とった

実際に負荷試験を進めていくにあたって、何をどこまでやるのか、という問題があります。 まずなんとなく始めてしまうことも大事ですし、なんとなく納得いくまでやるってのもアリですが、その辺の考え方を整理してみます。 全体図 今回はこの辺。環境の用意はだいたいできて、ではどんな感じで進めていきましょうかって話。 まずは始めてしまう 前にも（リクエストの分類）触れましたが、まずは簡単なシナリオを作成し、その動作確認と、ユーザーセッションなどの基本部分の取り扱いの正常性を確認してしまうべきです。この土台を整えないうちに、長々とシナリオ作りに精を出しても、どうせ多くの調整を行うことになるので、まずは負荷試験という一連の流れを作ってしまいましょう。 それと同時に、実際のアプリケーションをテスト環境で動かし、デバイスでアクセスもしてみます。試験者はアプリ開発者ではないとすると、さすがにログやデータだけで、アプ

負荷試験シリーズ、書きたいことはイッパイある気がするんだけど、技術の総括的な感じがエグくて、どうしてもまとまりがなくなってしまう…… ということで、気分転換にザックリお絵描きしました。これで少しはテーマを切り取って小綺麗に書いていきやすくなったはず。 負荷試験の流れ それがこれじゃ！いくらでも肉付け項目が出てくるだろうけど、１画面に収める内容としては最小限としてほどよくまとまったはずである。 だいたい分かってもらえると思うけど、一応軽く説明はしておきます。長くならないよう、一言二言ずつで！ 環境 クライアント・リソース 負荷試験ツールを動かすためのサーバー(群)。EC2 や ECS Fargate などのスポットで起動して安く済ませる。使い捨て用途なので、環境一式を作ったり削除したりを、一手で簡単にできるようにしておくと吉。 負荷試験ツール 疑似ユーザートラフィックを発生させるためのツール

久々に負荷試験についての続編です。 様々な処理をチェックしていく上で、どのようなリクエストがあるのかってのを意識しておくと進めやすくなると思うのです。 少しずつ進める さぁ負荷試験をやりましょうってなった時、クライアントツールを用意して、アプリケーションコードとテストデータ、サーバーリソースを準備したら、ようやく大量のトラフィックを発生させましょうとなります。それにはシナリオが必要で、どのようなリクエストを投げるかを表したコードやデータを作成することになります。 このシナリオをどのように作るかは、目的や人によって異なるのですが、まずはじめに示しておきたいこととしては、一気に全部作ろうとしないで、少しずつ作りながら実行した方がよいということです。 負荷試験は何をどこまでやるのか、を考える必要があるし、実行してから何度も調整することが多くあります。そのため、最初から全部の処理を網羅して、割合を

新年あけまして地味なことから始めましょう。 ECS Exec におけるタイムアウト対策の雑多なメモで、AWS ECS Exec を使ってみたTips | 外道父の匠 の補足みたいな内容です。 問題点 引っかかった問題はシンプルで、こんな風にごく普通に execute_command を実行したときに、20分強経過するとプロセスが強制終了されるというものです。 ecs = boto3.client('ecs', region_name="ap-northeast-1") cluster = 'test' task_arn = 'arn:aws:ecs:ap-northeast-1:0123456789:task/test/0123456789abcdef' container = None interactive = True command = "/bin/sh -c 'echo ABC;

前回の考察をより実現しやすくするために、ECS on EC2 と Fargate でリソース構成にどのような違いがあるのか、をTerraformコードで追っていきます。 １つの設定で気軽に切り替えられる書き方にしていますが、実際にはそんな風にする必要はないので、ポイントを確認する感じで見てもらえればと思います。 構成の概要 ECS on EC2 と Fargate では、細かくは多くの違いがあるのですが、基本的な構成はそう違いはないとも言えます。このどっちつかずの表現は、以降のTerraformコードを見ていただければ、なんとなくわかってもらえると思います。 ただ、１つだけ大きめの違いがあり、on EC2 ではネットワークの選択余地があります。それはネットーワークモードが「awsvpc」か「bridge」かの違いです。 Fargate では「awsvpc」固定になり、タスクにPublicI