UbieでSREをしているdekokunです。この記事は Ubie Engineering Advent Calendar 2023 の 21 日目の記事です。導入Kubernetes (k8s) のワンショットのJobにサイドカーを組み合わせると、様々な問題が生じることがあります。Ubie社には、複数の言語で書かれた多数のマイクロサービスが存在します。そしてご多分にもれず、複数マイクロサービスの共通課題をインフラレイヤで管理するためにIstioやCloud SQL Proxy、AlloyDB Auth Proxyなどを使用しています。この記事では、それらサイドカーをJobと共に使用する際に直面する問題と、世の中でよく語られている解決策、および条件付きながら私たちがどのようにこれらの問題を解決しているのかについて解説します。k8s Job + サイドカーで発生する問題かつての私は"Job以外でサイドカーを使えてるしJobでも簡単に使えるだろう"と思っていましたがそんなに甘くはありませんでした。 k8s Job + サイドカーを使うと以下のような問題が発生します*1。問題1: コンテナの起動順序が不定サイドカーコンテナが起動する前に、メインコンテナの処理が実行され、失敗するケースがあります。例えば、メインコンテナがDB接続を必要とするのに、DB接続に必要なCloud SQL Proxyが起動していないために接続できない場合などです。これはjobじゃない場合でも似たようなことは発生しますが、その場合はreadiness probeなどを適切に設定することで回避することができます。もちろん、アプリケーション側で"DB接続に失敗した場合は再試行を続ける"や"起動時に数秒待つ"などの制御も可能ですが、多数のマイクロサービスが存在する状況ではできれば統一的に解決したいものです。問題2: サイドカーコンテナが終了しない問題メインコンテナの処理が完了した後もサイドカーコンテナは稼働し続けるため、本来メインコンテナの処理完了と同時に終了してほしいJobが終了しない問題もあります。これは、リソースの無駄遣いや管理の複雑化を引き起こします。世の中で一般的に語られている解決策以下が一般的な解決策です。コンテナイメージにshellさえあればあとはmanifestを修正することでパッとできるのが嬉しいですが、逆にいうと、shellが存在しない場合を想定した場合は、何らかのツールを作った上でmanifest上でもいくつか変更しないといけない点があり、また一見して何をしているのかわかりづらいmanifestになるため、少し複雑に感じられます。起動順の問題: Container hooksのlifecycle.postStartを定義すると、この処理が完了するまで後続のコンテナの起動がブロックされるため、コンテナの起動順を制御できます。終了しない問題: プロセス空間を共有してメインコンテナ内でサイドカーを終了させる、またはファイルシステムを共有してメインコンテナが終了したことをファイルに記録し、サイドカー側が定期的にそれを読みに行き終了する例: Teamsnap Engineering BlogKubernetes 1.28から入ったSidecar Container機能: この機能により、起動順と終了しない問題が解決されるようです。また、今後さらに複雑な終了順序の制御が可能になる見込みとのことです。参照: Kubernetes Blogこれが現在の一番の本命解決策だと思っています。12/14にリリースされたk8s 1.29でベータに昇格されましたので、待ち焦がれています。Ubieにおける条件付きの解決策Ubieでは、以下のような自作ツールを活用することで、manifest上では"command"欄を書き換えるだけで問題への対応が完結するアプローチをとっています。Jobコマンド実行前にサイドカーのヘルスチェック用のendpointを定期的に叩きサイドカーが準備完了になるのを待つJobコマンドを実行するJobコマンド完了後、サイドカーに存在する自分自身をシャットダウンさせるエンドポイントを叩き、サイドカーを終了させるistioやcloud-sql-proxy, alloydb-auth-proxyには"/quitquitquit"という、自分自身をシャットダウンさせるエンドポイントが存在するのでそれを叩くだけで終了してくれます上記を読んで分かる通り、このアプローチは、サイドカーに自分自身をシャットダウンさせるエンドポイントがある場合(そしてもちろんヘルスチェック用のendpointが存在する場合)にのみ適用可能ですistioの場合の実行イメージ図。ツール名は"jobtio"例えば "sleep 1" をするだけの単純なJobの場合は、"jobtio sleep 1"のように書き換えるだけで上記の動作になります。なお、 Istioに関しては、基本的にネットワークに関するものであるので起動順の問題に対しては"Global Mesh Options"のholdApplicationUntilProxyStartsを設定することで最初に起動するようにしていますが、終了しない問題についてはやはり同様に上記記載のいずれかの方法での対処が必要です。現在の課題と今後の展望現在、istio/db系のサイドカー用にそれぞれのツールが存在する状態です。複数のサイドカーを同時に走らせたい場合を考えると、それらのツールを統合して複数のサイドカーを管理しつつ、起動順と終了順の依存関係を解決するツールを開発したい、というのが今後の課題としてあります。また、基本的にjobとサイドカーを使うすべてのコンテナにこのツールをばら撒かなくてはいけないため、配布方法も考える必要があります。現在は素朴にコンテナイメージに同梱していますが、例えばInitContainerでツールをコピーするなど、manifestの変更で配布が完結する方法も考えられます。ただ、元からのイメージに存在しない実行ファイルが実行されるというのは本来セキュリティの観点からは防ぎたいところではあるので悩ましいなと感じているところです。*1:この問題を初めて知ったのは、前職時代、以下ページを読んでです。ありがとう id:pokutuna さん: k8s Job + Sidecar の悲しみ - pokutuna

Kubernetes Jobでサイドカーを動かす際の問題と解決策

6月いっぱい、転職による有給消化期間なのだが、有給消化期間中にやりたいことの一つに簿記の試験を受けるというのがあった。ので勉強して受けたら合格した。受けたかった理由財務諸表の読み方がよくわかってない。勤めている会社の状態をお金という側面から知ることができるようにしたい！という気持ちがずっとあったこれまで、会計関連の本を何冊か読んだことはあったが、すぐに忘れていった。もうちょっと身になる方法を探していた経済学部出身でお金回り詳しそうなのに簿記をとってない。。。(簿記の講義は受けたがずっと寝ていた)、という悲しさがずっとあったまぁそもそも、経済学部の中でも商学科と経済学科に分かれていて、私は経済学部出身で簿記は経済学科の専門ではない、みたいな意見もあるが、なんとなくずっとしこりとしてあった会社で"簿記どうっすか"と皆に聞いてみたところ、"とったけど役に立ってない"という意見のほかに、経営者たちと話せるための共通のボキャブラリとして持っておくと便利という話があった勉強方法当方ITエンジニア。特に事前知識はない状態からのスタート(上記書いたように、数年前に会計関連の本は読んだが、もう完全に忘れている。貸借対照表と損益計算書がそれぞれ現時点での資産の状況を表す/特定期間の損益の状況を表す、くらいの知識は持っていたがそれくらいならググれば5分でわかる内容である)。イメージで攻略 わかる！ 受かる‼ 日商簿記３級 という試験対策本を一通り読んでこの本に記載の問題を解いた。だいたい15時間くらいで最後に付属している模試も含めて解けた。この本は、アイコンでのイメージ化が売りらしいが、特にその恩恵は一切感じなかった。勘定科目ごとにアイコンがあり、その色で資産か費用か、みたいな勘定科目のどのグループに所属するか、みたいな分類がされていたようだが、どの色がどれかまったく覚えられなかった(アイコンの名前の敬称が"さん"か"くん"かでホームポジションが貸方か借方かわかるようにもなっていたがそちらもどっちがどっちか全く覚えられなかった)。このあたりは、勘定科目それぞれの意味を把握すればどこに所属するかはだいたい一発なのでアイコンの意味が分からなくても特に困ることはなかったが、たぶん人によってはこのアイコンのシステムがうれしい人もいる。。。のかな？？？仕訳あたりは非常に面白かったが、仕訳したものをいろいろな帳簿に転記していくのが非常にだるかった。しかし、これによって財務諸表がどのように組み立てられているかがなんとなくわかった。一通りやっただけで以下かいた通り合格したので、比較的優れた対策本だったといえる。検索したりすると"簿記3級には100時間の勉強が必要"とか出てくるが、この本のおかげで15時間で合格したので、やはり優秀な本だったのであろう。ただ、ギリギリではあったので、あと2時間ほどかけて模試をする回数を1回でも追加していればもっと盤石な状態になったとは思う。受験結果合格した。ただ、70点が合格点で74点だったので非常にギリギリだった。時間も足りなかったし、これは模試的なものの数をもう何度かこなすともっといい点が取れたであろう。感想まだ経営者たちと、簿記で学んだ用語を使って会話するイベントは発生していない。が、お金について知ることで、お金を用いて仮説を立てるということがしやすくなるのは仕事をやっていくにおいての大きな利点だなとは、そのようなことを仕事でやっている妻と会話していて感じた。このあたりは実際の仕事で掘っていきたい部分である。以下、雑多な感想。簿記3級、15時間位の勉強で取得できて財務諸表をどうやって組み立ててるかがわかるしなかなかタイパが良いと思う(既に合格したつもりのツイート)。あと、私が本当にやりたかったのは簿記ではなくビジネス会計検定っぽかったな、というのも15時間で学べたので更にお得。— でこくん (@dekokun) June 26, 2023 簿記3級合格(点数はギリギリだったが、まぁ時間が足りなかったのでな。。)！！財務諸表の構築の雰囲気が学べてよかったです。取得へ背中を押してくれた現職はてなの皆さんに感謝。— でこくん (@dekokun) June 26, 2023 勉強も含めて非常に楽しかった。こういう、いろんな分野の最初の一歩みたいなのはどんどんやっていきたいですね。タイパいいと思う。

15時間くらい勉強して簿記3級に合格した

ここ数ヶ月、そんなに規模は大きくはないが複数人が関わるプロジェクト管理的な仕事をしていた。計画から実施まで。非常に楽しくやらせてもらっていた(先日終わった)。それをやっていく上で私の目指す生き方がだいぶ言語化できるようになってきた気がするのでここに書いてみる。正直全然まとまっていなくて、現時点での思考のスナップショット的な内容である。プロジェクト管理、やればやるほど最終的には、ゴールを決め(表の目標は与えられることもあるが裏目標は自分で考えられる)、ゴールを変えた方が良くはないかというのを考え、ゴール達成に向けてのリスクの大きいところはどこか、というのを探し、リスクの大きいものをなるべく早めに省コストに潰し続けながらプロジェクト全体を進捗させていく、というものなのだろうな、これを人々はプロジェクト管理と呼んでいるんだろうな、みたいな気持ちになっている(PMBOKとか全然読んだことないので完全に私の感覚だけで語っています。また、それらを達成するために何をするかのプラクティスもめちゃくちゃ重要であるが、そこはまだ詳しくないしテーマがずれるので語らない)。そして、プロジェクトが終わった後も"ゴールはそれで正しかったのか"を観察し続けるのも大事。ゴールを決め、最初はざっくりとした計画を立てつつ、リスクが大きそうなところはある程度緻密に計画をたて、進むに従って知識も増えてリスクが下がっていき(というか、より効率よく知識を増やすことでリスクが減るように進め方を調整する)、次第に緻密な計画がコスト低くできるようになっていく、みたいなのをひたすら繰り返し、ゴール達成した後はゴールが正しかったかを観察し続ける。不確実性コーンは時間の経過・タスクの進捗と共に勝手に減っていくというのもあるんだけど、減らすための動きを取り続けるのが大事なんだということがプロジェクト管理を通して肌で感じられたというか。上記の流れがいろんなレイヤで発生する。1プロジェクトの中の細かいタスク毎でも上記は考えられるし、そのタスク毎のゴールの総体としてプロジェクトがあり、プロジェクトはまた大きなプロジェクトの中の一部となり。。。最終的には人生のゴールに向けてプロジェクトが何重にも階層構造をなす、みたいなイメージを持っている。そして1つのプロジェクトの進捗や完了・その観察はまた別のプロジェクトの不確実性コーンを狭めるために(というかゴールを設定する・達成するために)使われる、というか。翻ってこれは人生でも同様で、とにかく人生における大失敗って何か(例：お金を貯めること・子供がいい大学にいくこと)を幸せだと思い込んで突っ走ってって最後に"実際にそれはそんなに重要じゃなかった"と思って死んでいくことだと私は思ってるんだけど、そうしないためには上記と同様のことを考えると勝率高そうだなぁと思っている。例えば、ここ2年くらいで 小動物を色々な種類飼ったり、植物を色々な種類育てている 中で、"「飼育・育成」と一口に言っても、自分はこういう特徴を持つ動植物を飼育するのに幸せを感じるんだ"みたいなのが見えてきていて、これは確実に人生のゴールを探索する・ゴールを達成することに対してプラスだな、みたいな気持ちになるわけですよ。この辺りは、"自分のやってみたいことをどんどんやったら人生が好転するのでは？"という雑な仮説を置いて進めた結果、うまくいったのではないかと思っている事例。不確実性の高い現代において、仮説を置いてガチャガチャ色々やりながら情報量を増やしつつ結果を眺めて仮説を修正し、ゴールがわからない状態でも人生の総体としてのゴール達成についてのリスクを減らしていく、それを意識して生きていきたいと今は思っている。このエントリ、言ってることの汎用性があまりにも高すぎて"書いてあることは当然じゃないか、それをどう達成するかが問題なんだよ"という気分もあり、何も言っていないに等しい気もするんだけど、これを書き残しておくことは大事であろう。アジャイル宣言の "計画に従うことよりも変化への対応を" みたいな話なのかなこれは。"Plans are nothing; planning is everything." もプロジェクト管理を進めていく上で私が大好きになった言葉です。計画を立てるのはとても大事だが、一度計画を立てたらその計画はそのまま実行するためのものではない、という感覚。人生のゴールってなんなんだろうねここから内容が主題とどんどん離れていきます。上記、"とにかく人生における大失敗って何かを幸せだと思い込んで突っ走っていって最後に「実際にそれはそんなに重要じゃなかった」と思って死んでいくこと"と書いているが、実際ゴールはどういう感じになるのだろうかというのは本当によくわからない。小学生くらいの頃は"子供を育てるか教科書に載るようになるのがゴールだ(遺伝子を残すかミームを残すか、的な)"とか言っていたが、すでに子供を育て始めている私としては子供が成長したらゴールというのも違うしなぁ、みたいな気持ちになっている。教科書に載るかどうかも、少なくとも現時点の私から見たら特にどうでもいいことのように感じられている。"子供が幸せになること"はゴールかもしれないね。幸せとは？？？直感的には"人生の幸せの総和を増やす"みたいな話も考えられると思うけど、それは違うのではないかという気もする。(そもそも幸せってなんなのか？定量化できるのか？みたいな話もあると思うがそれはおいておいたとしても)前半めっちゃ幸せで最後の最後で不幸だったら、なんかいい人生かって言われるとかなり怪しいと今の私は思っている。最近、私が一番ピンときているのは、"今があるならこれまでの選択は正しかった" と最後に思えるといいのかなぁということである。ただ、そのために何をすればいいかというのは非常に難しい、というか本当に最後の瞬間にしかわからない気がしていて、リスクの非常に高い状態。このリスクを低くしていくのが人生なのだなぁ。そのリスクを低くしていくために考えて行動していく行為自体が幸せの総和を上げていく、というのはありそう。ザ・ゴールという書籍を最近読んだが、この本は"企業の目的はお金を儲けることでそこに対するスループットを最大化せよ(そのためのボトルネックを見つけろ)"というのが主題で、それはその通りだと思うが、では人生は？幸せのスループットをあげていれば良い？？そもそも幸せとは？？？？ザ・ゴール作者:エリヤフ ゴールドラットダイヤモンド社Amazon余談だが、上記の"今があるならこれまでの選択は正しかった" というのは以下漫画のセリフからの引用(セリフは正確じゃないかも)である。初めてこのセリフを読んだ時は私は感極まって泣いてしまった。実際、大学後半から10年間くらいかなり辛いことがたくさんあったが、今の幸せから見ると、"当時の自分があるからこそ今の幸せがあるのだなぁ"という気持ちになれている。たびしカワラん！！（１） (裏少年サンデーコミックス)作者:江野スミ小学館Amazonどんどん余談が増えていくが、そういえば高校時代にスピーチで"人生とは絶望の砂漠の中からたまに幸せの粒を拾っていく旅だ"見たいなことを言っていた記憶があり、まさにその通りだなと思う。まとまりがなくなってきたので終わる。幸せな人生を送りたいものだ。

ゴールを探索しつつゴールに対するリスクを減らしながらゴールを達成していくのかが人生ですねぇ

AWSのDB、Auroraを使っているみなさま元気でしょうか。Auroraに限らずSaaS的なサービスを使っていると"このバージョンはEOLだ"と言ってバージョンアップが必要になる場合があります。みなさまも覚えがあるのではないでしょうか。問題はどのようにバージョンアップを行うかです。今回は、Aurora MySQL (not serverless)でマイナーバージョンアップを行う際にどういう手法があるかを、AWSのドキュメントや実際にやってみた経験をもとに考えたいと思います。Aurora PostgreSQLも同様かもしれませんがそちらは調べていません。目次目次考えられる方法2つそもそもRDSのブルーグリーンデプロイメント機能とは？それぞれの嬉しい点、使いづらい点インプレースアップグレード(ゼロダウンタイムパッチ適用を狙いつつ)嬉しい点使いづらい点ブルーグリーンデプロイメント嬉しい点使いづらい点筆者はどうしている？考えられる方法2つ大まかに、以下2つの方法があるかなと思います。RDSに最近出たブルーグリーンデプロイメント機能を使ってバージョンアップインプレースアップグレードを行う(DBのバージョンをそのまま上げる)ゼロダウンタイムパッチ適用が効いて接続が切断されずにupgradeが完了する場合もある他にも手動でブルーグリーンデプロイと似たようなことを行う手法などもあるかと思いますが、RDSのブルーグリーンデプロイメント機能を使う場合と特にメリットデメリットなど変わらないかと思うので今回は割愛します。そもそもRDSのブルーグリーンデプロイメント機能とは？AWSが提供するRDSの機能で、既存のDBのデータをコピーした環境が新たに作成されてそちらで動作確認などができ、その後切替をするとDBのDNS名が新旧で切り替わり、アプリケーション側の変更なしでDBが切り替わる機能。なお、"ブルーグリーン"と聞くと切り戻しも簡単にできそうに思えてしまうが、切り戻しはできない(切替後は新しい方にデータが書き込まれるのでナイーブに考えると"そうだね"、とはなる。新しい方から古い方へデータの反映が必要な場合は自前で頑張ってね、ということである)それぞれの嬉しい点、使いづらい点インプレースアップグレード(ゼロダウンタイムパッチ適用を狙いつつ)嬉しい点非常に気軽。webコンソールで実施しても"ぽちぽちぽち"くらいで完結するゼロダウンタイムパッチ適用 が効いた場合、それまではられていたコネクションの切断すら発生しないで切り替わるもしゼロダウンタイムにならない場合でも、20~30秒くらいのダウンタイムで完了するAmazon Aurora MySQL のデータベースエンジンの更新 - Amazon Aurora によれば、 更新では、DB クラスター内のすべてのインスタンスでデータベースを再起動する必要があるため、20 ～ 30 秒のダウンタイムが発生します とある実際自分で何度かやった感じ、10秒程度のダウンタイムしか発生していない使いづらい点厳密に切り替えの時間が制御しづらい。"大体15分以内には完了するかな"くらい時間がデータ量に関連するかは不明(マイナーバージョンアップでは多分データ量は関係しないが裏は取っていない)ゼロダウンタイムパッチ適用が効くかどうかは最後は運(ベストエフォート)。以下を見れば確率を上げることはできるが、確実にゼロダウンタイムパッチ適用が効くとは言えないAurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード - Amazon Aurora実際に12DBやった事例を聞いたが、5/12でゼロダウンタイムパッチ適用が効かなかった。5割以上は効くが、9割効くとは言えない、くらいのイメージでいるといいか。ゼロダウンタイムパッチ適用時の性能への影響がよくわかってない。mysqladmin pingを毎秒飛ばしてアップグレードを試していたら、connect-timeoutを1にしている場合は何度か接続が失敗した使ってるバージョンとインスタンスタイプの組によってゼロダウンタイムパッチ適用がそもそも動かない場合がある参照：Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード - Amazon Auroraブルーグリーンデプロイメント嬉しい点そこそこ気軽。binlogさえ出力していれば、ポチとしてから1時間くらい待って新しい環境が構築されてから再度ポチとすれば切り替わるインプレースよりは手軽さはない切り替え対象の新しいDBができてそれに対して検証を行うことができるため、事前の検証が楽。切り替え時にも"まさに検証を行ったDBをそのまま本番環境に使う"というのはだいぶ気持ちの面で気楽であろう切り替えの時間制御がそこそこできる。大体"ポチッとしてから数分以内に完了するであろう"という確信が持てる(一定時間を過ぎたらロールバックする機能もある)ダウンタイムが短いはず。どれくらい短いかはパッと見ドキュメントがなかったが、適当に試したら30秒以内には切り替わったログを見た感じ実際に内部でやっているのは、クラスタの名前の付け替えくらいっぽい？デフォルトで切り替え後に旧マスタDBが残っているので、切り替え直後に何かあった際の調査や最悪の場合の切り戻し(切り替えてからの更新内容の反映方法は考える必要があるが)が楽使いづらい点binlog出力が事前に必要。binlogの出力設定を変更するためには再起動が必要最近はbinlogを出力しても性能劣化はあまりないという話(参照： https://developers.cyberagent.co.jp/blog/archives/29925/ の"ベンチマーク"部分)もあったので、基本的にbinlog出力しておくと良いだろうとは思っているしあまりデメリットにはなりづらいと思うインプレースアップグレードと比べると全体のプロセスにちょっと時間がかかるデータの少ないDBでもブルーグリーン作成をポチしてから1時間ほどで準備が整い、それから切り替えボタンをポチすると5分くらいで切り替わる、という世界遅延読み込みの対処が必要以下の"ブルー/グリーンデプロイを作成する際の遅延読み込みの処理"にある通り、新環境が構築されたすぐにはデータ読み込みのペナルティが存在し、暖機運転などが必要になるブルー/グリーンデプロイの作成 - Amazon Relational Database Service筆者はどうしている？インプレースアップグレードのゼロダウンタイムパッチ適用が強力かつダウンタイムが発生した際のペナルティも少ないので、マイナーバージョンアップの際は基本的にそちらを狙っていけばいいんじゃないかなと思っていてインプレースアップグレードをしている常にbinlogを出しておいて、どのバージョンどのインスタンスタイプでも、メジャーバージョンアップの場合でも同じ手順を使うためにブルーグリーンデプロイメントを常に採用するという判断もよさそうに感じるメジャーバージョンアップの際は事前に動作確認できるという面でもブルーグリーンデプロイメントは非常に便利

Amazon Aurora MySQL のマイナーバージョンアップ、ブルー/グリーンデプロイメントを使う？ゼロダウンタイムパッチ適用を狙う？

こちらははてなエンジニア Advent Calendar 2022 - Hatena Developer Blogの46日目です。1/15日の分なのですがフライングでの投稿です(日付を間違えてた)。昨日は Perlでテーブル駆動テストを書くのにハマっている - NaaN日記でしたね。テーブル駆動テストのことを知ったのは私は数年前にGo言語のテストを書き始めてからですが、いつ頃から流行り始めたのかがちょっと気になる今日この頃です。このエントリにもLambdaのテストについて書いてありますが、このテストコードもテーブル駆動で書いています。テーブル駆動テスト大好きです。やりたかったこと色々なチームが相乗りしているAWSアカウントのGuardDutyの検知を、自分のチームに関係のあるイベントだけ通知する、というのを実装したかった。検知結果を自分のチーム専用にいい感じにフィルタして通知したい、という感じ。構成案"GuardDutyをSlackに通知する" みたいなのを検索すると、大体以下2案のどちらかが出てくる。今回はこの2案からどちらを選ぶかを検討した。ある程度シンプルな形でGuardDutyの結果をslack通知するのであればこれくらいの選択肢しかないだろうと思っているがもっといい案がある人は教えてほしい。案1: GuardDuty -> EventBridge -> SNS -> ChatBot -> Slack案2: GuardDuty -> EventBridge -> Lambda -> Slackどちらの案を選ぶか決める際に考えたこと案1はLambdaを使わなくても構築できる。つまり、Lambdaのコードを書かなくてもIaC的なコードだけで管理できる、という嬉しさがありそう。案1でも案2でもGuardDutyの検知結果のslack通知はできるが、上記"やりたかったこと"の内容を考えると、不要な通知をいい感じに排除する機構をどこに設けるかが結構重要なポイントになってくるかなと思う。一般的には、GuardDutyの抑制ルールでフィルタするものかもしれないが、この抑制ルールはGuardDutyの設定全体に効くものという理解なので、複数チームで1つのアカウントのGuardDutyを見ている状況で自分のチーム向けのルールを設定するのは行えない。案1だったらAmazon EventBridge のイベントパターンでのフィルターやSNSのメッセージフィルターでフィルタを行うことになりそう。案2だと、Amazon EventBridge のイベントパターン以外に、Lambdaで動かすプログラムで素朴にフィルタするようなコードを書くという選択肢が手に入る。EventBridge側でフィルタを行うと、後続の処理が走らなくなるのでコスト的な優位性は存在する。ただ、そのAWSアカウントのGuardDutyの検知のオーダーは、日に数百件とか数千件とかくるわけでは全くなく、かつslack通知を行うlambdaも非常に簡単な処理になるので、後続のタスクのコストは考えなくて良い程度のものになる。また、不要な通知はいい感じに排除する、というのは運用の中でフィルタする条件もどんどん変更されていくことが想定される。その際にEventBridgeのイベントパターンやSNSのメッセージフィルターを使って実装すると、フィルタの条件が複雑になってくるにつれて"この変更は本当に既存の通知を壊していないだろうか"という不安が大きくなって変更速度が鈍りそう/実際に既存の通知を壊しそう、という懸念が大きいと考えた。変更の際の安心感を担保するには、テストの書けるLambda側でフィルターを実施するのが簡単であろう。イベントパターンやメッセージフィルターでも簡単にテストができると良いのだが。結果上記の通り、フィルタ条件変更時の安心による速度向上を狙って案2で、通知のフィルタをLambdaで実装する方式を採用した。テストが普通のアプリケーションと同様に書けるのは書きやすいし安心。気になりAmazon EventBridge のイベントパターンでのフィルターやSNSのメッセージフィルター を手元から簡単にテストする方法はあるだろうか。E2Eテスト的なものを作るしかないという認識だが、うまい方法があったら是非とも知りたい。

GuardDutyの検知結果をslack投稿するアーキテクチャを考えた(あるいはAWSでイベントのフィルタを行うときに考えたこと)

この記事ははてなエンジニアのカレンダー | Advent Calendar 2022 - Qiitaの9日目のエントリです。会議を司会として設計する際に、司会だけでなく、皆で今やってる会議をより良くしたいし今後の会議もより良くしていきたいと思って実践しているいくつかの手法を紹介する。非常に一般的な良くある手法が多いと思うが、実際に私がやってみてどうだったか、というのも記載している。最近の私の状況最初に会の目的を宣言する狙い実際にやってみてどうだったか予備時間を作っておく狙い実際にやってみてどうだったか議題ごとに細かく時間を決め、宣言しておく狙い実際にやってみてどうだったかいつでも誰でも感想が書き込めるコーナーを議事録会場などに作って会の最初に宣伝しておく狙い実際にやってみてどうだったかこのエントリを書いての感想まとめ最近の私の状況最近いろんな会議を設計・司会している(以下、一般的には会議とは呼ばないかもしれないが"目的をもって複数人で時間を区切って何かをすること"をこの文章では"会議"と呼んでいる)障害対応演習新機能追加の流れをより早くするための課題の洗い出しチームの持つサービスに皆でより詳しくなるための会これら、皆に手を動かしてもらったりを初めてやっていくような際に、ある程度うまくやりつつ、次回以降をより良くしていくためのTipsをいくつか意識してやっているので紹介以下で、実際にやってることとその狙い、および実際にやってみてどうだったかについてを書く。最初に会の目的を宣言する会議の目的を書いておき、会議の最初に宣言する狙い会議の目的を宣言しておくことで、参加者がどう振舞うと会の目的が達成できるか自分で考えられるようになり、各人がさまざまな判断をしやすくなる実際にやってみてどうだったか参加者から会議の感想として、"狙いがあったのでどう振る舞えばいいかわかりやすかった"というのをいただけた予備時間を作っておく時間配分を設計する際に、予備時間を定めておく。30分のmtgだったら5分くらい。2時間で15分とか。狙い"ここはより時間を費やして話せばより会議の目的達成に近づきそうなので予備を投入しよう"という判断ができるようにし、司会が積極的に会議の内容に介入するための武器の1つとする。いわゆる"予備兵力の重要性"みたいな話であるもし何もなかったら早く終わればいい。時間の有効活用の役に立つ実際にやってみてどうだったか完全に狙い通りの効果が出て非常に司会がやりやすくなった予備の時間が完全に余ることもあり、そういうときは余った時間で、以下の "いつでも誰でも感想が書き込めるコーナー" にみんなで感想を書き込む時間にすることもできたし、狙い通り早く解散することもできた。議題ごとに細かく時間を決め、宣言しておく話題の区切りとなる部分をできる限り細かくしておき、それに適当でいいので時間を当てておき、議題毎に宣言する狙い1時間の枠だけを考えて時間管理をするよりも5分とか10分とかの枠を考えて時間管理する方が圧倒的に楽なはず。いわゆる分割統治各人が時間の制約の中で目的を最大化するための行動が取れるようになる時間の制約がわからない場合、常に"この話題で自分はこれだけしゃべっているけど大丈夫だろうか"とか、"司会はちゃんと時間を把握してるだろうか"という不安と戦うことになるであろう実際にやってみてどうだったか"時間が迫ってきたので、今の議題の締めに入るか、予備時間を投入するか" という2択を、議題毎に考えるイベントが強制的に挟まれるので非常に適切に判断しやすくなった実際、先日、時間を決めて宣言するのをサボった会を主催したが、1つの議題で結構時間が経過しても参加者から"時間大丈夫ですか"という発言が出るまで"ここで切る"という判断が遅延した時間を切っていけるので無駄にダラダラ話すことにならない議事毎の時間を決めておくことで"この議事はちょっと時間が足りなかった"という振り返りがしやすくなり、次回以降さらに時間の割り振りをブラッシュアップしていくたたき台とすることができたいつでも誰でも感想が書き込めるコーナーを議事録会場などに作って会の最初に宣伝しておくscrapboxに会議ページを作り、それ専用のコーナーを作っておいて誰でもいつでも書き込める状態にしてある次回以降、より良くするための感想コーナーを事前に作っておいて皆に書いてもらう狙い各人から感想が1箇所に集まり、次からの会の改善に活かす実際にやってみてどうだったか司会をしながら気づいたことでもすぐに書き込めて便利(司会専用のメモであればなんでもいいけど)なんとなく言い訳をしたい時に皆が見ることのできる会場に"こういう狙いを持ってこうしたが失敗だったかも、次はこうしよう"的なことを書いておくことで、気持ちが晴れる。不安は判断を鈍らせるのでね参加者からめちゃくちゃたくさんの意見をもらうことができて実際にそれによって次回の会議を改善できている実際にこのエントリに書いたようなことはこのエントリを書いての感想このエントリを書いていて、いくつか気づいたことがある。まず、時間の配分というのは、より良い会議にするための司会者が持つ強力な武器だということ。また、この武器はうまくやれば司会者のものだけにせず参加者にも分配することで会議をさらに良くすることができるのではないかということ。これから会議の中身を考えるときはその辺りにも注意を払っていきたい。また、たまにタイムキーパーと司会が分かれている会議も存在するが、それはあまり嬉しいことはないのではないかという気持ちも出てきた。ただ、時間の弾力的な運用を全くする必要がない会議・話すこと自体が最も重要で時間内に結論を出す必要がないような場(それは会議とは呼ばないかもしれないが)などではタイムキーパーがいることで司会が議事だけに専念できる、という効果はあるのかもしれない。 冷静に考えると、"事前に決めていた時間を超えたよ"というイベントをタイムキーパーに投げてもらえるなら司会は時間を気にしなくて良くなって便利だわ。その上で、司会は事前に決めた時間に従うかどうかを考えれば良い。タイムキーパー、いた方がいいですね。まとめこのエントリの内容は全体的に、"事前に考えておいてそれを皆に周知しつつ、実際に起きたり皆が感じたりしたこととの差分を補正していく" という話であり、さらに端的にいうと、"計画とその共有、それに対するフィードバック"が重要であるという話なのであろう。

みんなで会議をよくしていこう！と思ってやってるTips

やりたいことdocker buildに失敗した際に、試行錯誤するためにdocker buildに失敗した直前の状態でdocker runしてデバッグしたい。失敗してなくても、とにかくdocker buildした際の任意のステップに対してdocker runしたい私の知ってる既存の手法(面倒)私は以下のようにしてBUILDKITを無効にしつつdocker buildするとDockerfileの各ステップ毎に"---> deadbeefxxxx" みたいにイメージのIDが出力されるからそれを使ってdocker runしてる。DOCKER_BUILDKIT=0 docker build.悩み面倒ではないか？わざわざBUILDKITを切ってビルドし直すのも出力をコピーしてきてdocker runするのも、なんかあと1ステップくらい減らすツールが世の中にありそうな気がしている。もっとシュッとできるかっちょいい方法ないもんですかね。例えばdocker buildして失敗したらそのままdocker runされるやつとか、docker buildして失敗した直後にコマンド打ったら勝手にdocker runしてくれるやつとか。自分で実装するとしたらどう作るといいかな〜〜。

求む、docker build に失敗した場合のデバッグ手法のかっちょいい方法

k8sjp.connpass.com先程登壇させていただいた。2年半ぶりの社外登壇である。その後一人で反省会をしていた。KeepLT登壇申込みに至る流れが非常に良かった。会の1週間ちょい前くらいにイベントを知って勢いで申し込んだ。勢い大事にしていきたい社外登壇が久しぶりだし時間もないので仕事関係なく、最近書き溜めていた個人活動についての話にして時間を節約しようというハードルの下げ方も良かったこのあたりは、昔ほど時間を無限に費やせないから妥協しているという話ではあるが、自分の生活に合った妥協ができている一緒にブログも一本書けた個人運用k8sクラスタの構成要素の技術選定 - でこてっくろぐ ねおブログを最初に書いて時間があればスライドを作るしなければブログのまま発表するというフォールバックプランがうまく働いて焦りもなくフォールバックプランを実行できて前日もよく寝られた仕事でEKS/GKEを使ってることを話せた同僚も"今日発表準備大丈夫ですか。時間取ったほうがいいんじゃないですか"とか気にかけてくれてありがたい運営からのメールを読んで事前にzoomのセットアップをして背景などをいじったり画面共有をしたりの準備をした(ので以下problemにあるように直前確認への参加を忘れてしまったけどかろうじてなんとかなった…)今回の発表準備では、 "初心者の技術選定でも深ぼれば面白い" という思想をずっと持ってやっていた。この思想自体は最高だと思っているうまく深堀りできたかは別の話特に久しぶりの登壇なので、この振り返りを書いて次に活かそうとしている事自体が圧倒的に素晴らしい！Problem発表の見た目がかっこよくない(他の人のかっこいい発表資料を見つつ)ブログをそのまま発表に使うスタイルについて最終的に、発表に使う下書きブログと公開するブログの2つを管理することになって辛かった自分の中の面白さ重視で"発表前に資料を公開したい""けど、発表資料にはブログとは違うもの(自己紹介とか)入れたい！"ってやってたせい。事前に資料公開すること自体そんなに発表にプラスでも無い気もする。このあたりはどうだろうかLTなのに話す内容を精査できずとっちらかって中途半端このあたりはもろにブログをほぼそのまま発表資料にしている弊害が出ている。ブログが書き上がったらなんとなくできた感が出てしまって整理する時間を取ってないという話懇親会不参加参加する気まんまんだったんだけど、zoomでそのままやるのかと思ってたら出鼻をくじかれて別ツール(remo)だということがわかりセットアップしてるうちに"もうあっちでは盛り上がってるんだろうな"と思うと参加できなくなってしまってこのエントリを書いている。。。コミュニケーション力！！！！事前に懇親会のツールの連絡もメールで来てたのに！！ちゃんと確認しろ！運営の皆さんすみません…"懇親会が本番"！！！せっかく発表したのに！！！！当日、"発表者はこの時間に来てください"というメールが来てたのに忘れて会の開始時間に参加した…運営の皆さんすみません…Try運営からのメールはよく読んであますところなくセットアップしましょう次は何かしらの登壇、もっと早くから申し込むぞ！私はやることさえ決まればコツコツすすめるのは得意なので、早く申し込めば上記の問題がだいたい解消すると勝手に考えているバーっと書いてから、伝えたいことを意識しつつ内容を捨てていく時間をたくさん取る懇親会でのツールを確認しておくぞ！仕事での何かも話してぇ(何話そうか適度に飲酒してLTもしてみたい(上のProblemとは関係がない感想他の皆さんの発表内容も私の発表もめっちゃ楽しかった！やっていくぞ！運営の皆さん勉強会開催ありがとうございます！！！！！！(発表練習に行かず本当に申し訳なかったです…

Kubernetes Meetup Tokyo #48 LT 登壇の一人反省会

これは、k8sクラスタを個人で運用する際に行った構成要素の技術選定の記録である。技術選定の理由を書くのも見るのも楽しい、という心情のもとにここに公開する。前提知識以前、こんなエントリを書いた。bitcoinのfull nodeをAWSでなるべく安く運用してみる - でこてっくろぐ ねお上記の通り、個人でbitcoinのfull nodeという、状態をバリバリもつサービスを、AWSでのコスト面で最安を狙って作り運用を行っていた。しかしその後、Oracle Cloudで運用したほうが安くなることに気づいたため引っ越した。Oracle CloudではARMのVMが4台無料で使えて複数台構成が組め、AWSやGCP同様k8sのマネージドサービスもあり、また仕事でk8sを扱う部署に異動したのもあり、勉強のためk8sクラスタ上で運用することにした。構成要素以下の構成要素を選択している。以下の中でも"☆"のついたものについて詳細を掘り下げる。☆ クラウドOracle Cloudマネージドk8sサービスOKE(Oracle Container Enginer for Kubernetes)☆ ソースコード管理githubのpublicリポジトリマニフェスト管理Helm☆ CIGithub Actionsマニフェストの検証： kubeconformマニフェストの差分の検知： jestのsnapshot testhelmの設定の検証： helm lint依存関係の更新検知： RenovateCDArgoCD☆ 秘密情報の管理bitnami-labs/sealed-secrets☆ 監視Mackerelイメージ管理docker hubのpublic imageクラウドにOracle Cloudを採用Oracle クラウドが私のユースケースではコスト的に最安だったため選択。以下がすべて無料で使えるため、結構な範囲の個人ユースには価格的には最適なのではないかと思っている。ARMインスタンスを4コア・メモリ合計24GBAMDインスタンスを2台それぞれ1/8コア・メモリ1GBARMインスタンスと共にクラスタを組み、ARMをメインにしつつARMイメージが公式に無く性能の不要なコンテナをこちらで動かしているブロックストレージ 合計 200GBNAT GatewayAWS でNAT Gatewayの下に構築した際はbitcoinの初回起動時のブロック同期(IBD)でInboundの転送量だけで数千円かかって泣きそうだったOutboundのデータ転送、月に10TBbitcoinのfull nodeはブロックデータをpeerとやり取りするため意外とデータ転送量を食うNetwork Load Balancerbitcoin full nodeはHTTPじゃないプロトコルを話すので必要詳細： Oracle Cloud Free Tier | Oracle 日本ソースコード管理ソースコードの管理(主にマニフェスト)にはgithub の public リポジトリを採用している。github.comprivateにするという判断もあったかと思われるが、publicリポジトリだとGithub Actionsが無料で使えて大変便利であり、publicにしておくと"ちゃんとしないといけない"圧力が自分で自分にかかって勉強になるという利点もある。また、発表の場やブログなどで実例を社内外にリンクで紹介できて楽というのも見逃せないポイントとしてある。このエントリ内でもいくつかリンクを便利に使っている。CIマニフェストを適用しないとエラーが発覚しないのはたいへんダルいので、CIも整備してある。pull requestに対してGithub Actionsが発火する形のCIとなっている。CIでは以下のチェックを行っているマニフェストの検証： kubeconformマニフェストの差分の検知： jestのsnapshot testはてなで採用している技術を輸入してきたhelmの設定の検証： helm lintマニフェストの差分の検知にはjestのsnapshot testを実施している。helm template を実施してマニフェストを出力し、差分があるとテストが落ちる。また、差分があった際に変更行が出力されるため、意図しない変更が行われていないかを検知するのに役立つ。snapshot testについては、マニフェスト管理のためというよりはもともとViewのテストを行うために作られたという認識だが、ここで行っているマニフェストの差分検知のように、なんらか文字列を出力するものをテストするのに非常に優れている。詳細は以下のエントリを読むと良い。www.mizdra.netただ、jestを使わなくてもhelm templateの結果をgit commitしておくだけでも十分な気もしているのでそうしてもいいかなとは考えている。CIの設定の詳細はGithub Actionsのファイルを見てください： crypt-manifest/ci.yaml at main · dekokun/crypt-manifest · GitHub依存関係の更新補助依存関係の更新の補助にRenovateを採用している。Renovateがhelm chartの更新を検知してpull requestを作成し、github actionsがそれに対してsnapshotのupdateを行ってコミットし、人間はただその差分を眺めて良さそうであればmergeを行えばArgoCDが自動的にデプロイしてくれる世界になっている。renovateからのpull requestに自動的にsnapshotのupdateを行ってくれるgithub actionの設定： crypt-manifest/auto-snapshot-update-for-renovate.yaml at main · dekokun/crypt-manifest · GitHub機械が差分を出してくれるので人間はこのようにdiffを見るだけで良い： Update Helm release sealed-secrets to v2.1.3 by renovate · Pull Request #37 · dekokun/crypt-manifest · GitHubこの世界は非常に便利だったため、仕事にも輸出した。秘密情報の管理例えば、監視に使っているMackerelのapi keyをどのようにk8sに伝えるかは考えないといけない。github の public リポジトリを使っている以上、平文でマニフェスト内にベタ書きすると、バージョン管理に含められなくなってしまって運用が面倒になってしまう。最初に検討したのが、クラウド上のsecret manager的なものと連携するというものであったが、Oracle Cloudでかんたんに連携できるCSI Driverはパット見なさそうだったのと、あまりクラウドに依存したくないのと個人クラスタ管理には大げさに感じたので見送った。そこで、初期はhelm secretsのhelm wrapperを使ってhelmのデプロイ時にhelmの変数として突っ込むようにしていたが、ArgoCD導入時に調べたところArgoCDとの連携が面倒くさく思えたのでhelm secretsの継続は諦めた。また、helm secretsを使う場合は手元のマシンの中や、AWS の secret manager等自分で秘密鍵の管理方法を考えて管理しなくてはいけなかったのもネックである。その際にKubernetes完全ガイドを読んでいたところ、"sealed-secrets"というツールが紹介されており、上記欠点を完全に解決していたので採用した。github.comこのツールは暗号化したマニフェストファイルをデプロイするとk8s内で復号しSecretを生成してくれる。秘密鍵の管理はクラスタ内に閉じており、マニフェストファイルの暗号化の際も手元に秘密鍵は渡らないため安心して使うことができる。監視普段仕事で使ってるMackerelでどうするとより良いk8sの監視ができるのかを探るために採用。コンテナのサイドカーとしてmackerel-container-agentを動かしている。上記の通り、Oracle Cloudを無料で使うためにARMインスタンスを使用しているが、Mackerelも最近container-agentの公式イメージがARM対応したためパッと入れられた。mackerel.ioついでにbitcoin向けのMackerel pluginも作ったのでよければどうぞ。github.comまた、cronJobを使用して bitnodesからbitcoin fullnode の自分の順位の取得を行ってMackerelへの投稿もしている。順位の変動が可視化され、"この日full nodeが落ちから順位が下がってるな"などがわかって便利。感想久しぶりに個人で手を動かして何かを作ってるけど楽しいな〜〜〜

個人運用k8sクラスタの構成要素の技術選定

bitcoinのfull nodeをAWSでなるべく安く運用してみる

本記事ははてなエンジニア Advent Calendar 2020 の3日目の記事です。昨日は id:nabeop さんのcdktf に入門した話 - nabeo がピーしているブログ (仮)でした私はここ数年クラウドというとAWSばかり触っています。AWSに関してはre:Inventに参加したり Solution Architec Professional を取得したりとそこそこ扱える状態ではあるのですが、Google CloudやMicrosoft Azureについてはほとんど触ったことがありません。今回、Google Cloudも触れるようになりたい！と思いまして、ある程度全体像を掴むための一歩として手始めに資格を取得してみることにしたところ実際に資格を取得でききました。このエントリでは最初どういう状態から実際にどのような勉強を行ったか、ついでに私の受けた遠隔監視オンライン試験についてをこちらに記載します。勉強前の状態Google Cloud実務経験はなし数年前にISUCONで触った記憶はあるが何も覚えていない試験に向けて勉強したこと勉強したことは以下の通り。だいたい総計15~20時間くらい社内のslackに#gcp-certificationという、そのものずばりGoogle Cloudの資格取得を頑張る皆がいるチャンネルにjoinし、そこの有志で勉強会を開始、週に1度、ランチ時間の30分を使って皆で勉強を開始AWSの資格試験の時もそうでしたが、資格取得を申し込むためのアカウント作成が結構難関でそれを皆で一緒にできたのは大変ありがたかった[01] はじめてみよう GCP 基本編 - Google スライド を実際に手を動かしながら一通り行った上記の勉強会で教えてもらったので手始めにやってみた。全然知らないところをさらっと一通りできたのでありがたかったAssociate Cloud Engineer 模擬試験 | Google 認定プロフェッショナル  |  Google Cloud を受けた上記 "はじめてみよう GCP 基本編" で一通りできた気になったので"もしかしたらもう合格するんじゃね？"と模試を受けてみたところ50%くらいしか点数が取れなかった以下 "GCPの教科書" を読んだ後にも再度受験し、自分の弱いところが分かって最後の一詰めに役立ったGCPの教科書 | 吉積礼敏 | 工学 | Kindleストア | Amazon を一通り読んだこれを読んだ後に模試を受けたところ8割取れて、"合格点がわからないけど多分合格するのでは"という気持ちになったAmazon.co.jp: GCPの教科書II 【コンテナ開発編】 KubernetesとGKE、Cloud Run、サービスメッシュを詳解: クラウドエース株式会社, 飯島 宏太, 高木 亮太郎, 妹尾 登茂木, 富永 裕貴: 本上記、2回目の模試を受けた後に自分はGKEが非常に弱いということを痛感したのでこの本のGKE関連の部分だけ一通り読んだちょうど同僚がGoogle CloudのIAM設計やVPCの設計について考えていたので週に30分 * 2回、IAMの設計周りを教えてもらっていたQwiklabs(試験後に便利さを知った勉強ツール)今回の試験勉強では使わなかったのですが、試験後に知ったこととして、以下Qwiklabsというサービスが、Google Cloudを勉強するに非常に便利だということがわかりました。Qwiklabs - Hands-On Cloud Trainingいろいろなコースがあり、コースを始めるとコースごとにGoogle Cloudの専用アカウントが与えられ、その中でコースの内容に沿って実際にGoogle Cloudの設定を変更していく、というものです。コースの中にはいくつかチェックポイントが存在し、チェックポイントでは実際にそのGoogle Cloudのアカウントの中で正しく設定がされているかがちゃんと確認されるようになっており驚きました。有料ではあるのですが非常に有用なのでぜひお試しください。なお、現在、2021年1月まで、無料でいくつかのコースが受けられるキャンペーンをしているので、ぜひこちらで試してみるといいと思います。私はこのキャンペーンで試してみた結果、Qwiklab大好きになりました。Google Cloud スキルバッジキャンペーン同僚がこちらを会社費用で受けられるように調整してくれたので、次の資格を取得する際はガンガン使っていこうと思いました。遠隔監視オンライン試験について資格取得試験を当日どのように受けるかについて、実際に試験センターに出向くオンサイト試験と、遠隔監視オンライン試験の2種類から選ぶことができます。私はわざわざ試験会場まで出向くのが面倒だったので遠隔監視オンライン試験で受験することにしました。遠隔監視オンライン試験では、チャットで試験官とやり取りしながらPCのカメラを使いつつ部屋の隅々まで移したりしていてちゃんとしているなぁという印象でした。ただ、チャットでのやり取りが若干不自然で"本当にこちらの言うことを理解しているのだろうか"という不安が常にありました。また、多分後で画像を確認するなどするからだと思うのですが、実際に試験終了後に"合格"と出つつも"10日以内に正式な合格かどうかを判定します"という文言が出て、実際に1週間後くらいに正式な合格通知が来るまで結構不安な気持ちで過ごすこととなりました。感想新しいクラウドを大雑把に学ぶのに初級レベルの資格を勉強するのは非常に効率が良いというのを感じました。この技はまた新しいクラウドを学ぶ時に使っていきたいです。また、今回せっかくGoogle Cloudの勉強をしたので、今後は実務にも組み込みつつProfessional Cloud Architectを目指したいなと思います。明日のアドベントカレンダーはid:syou6162さんです。楽しみにしてます！qiita.com

 Google Cloud の Associate Cloud Engineer 資格を取得するためにした勉強

2ヶ月くらいかけて毎日盆栽のようにちょっとずつ手を入れていたツールがまぁいい感じになってきたかなと判断したので、紹介エントリです。2020/11/07 追記このエントリを書いた2日後に、以下AWSの新機能が出て、以下私がこのツールを作った理由として述べている部分は、AWSの機能で代替可能となりました。まぁ、このエントリを読むと分かる通り、AWSがそこを実装していることを前提として、"捨てやすくする"という方針で開発したツールではあるので狙いどおりではあるんですが、ちょっと悔しい気持ちもありますね。捨てやすくする以前に使わなくてよくなった、的な。AWS Fargate for Amazon ECS launches features focused on configuration and metricsCDKにもこの機能が来ましたので、もうなんでもできます。ecs: secret JSON field for Fargate tasksgithub.comどんなツール？github.com以下のように、JSONが格納された環境変数があった時に、その環境変数名と、JSON内のキーからexportしたいキー名を指定すると、そのキー名で環境変数を設定しつつコマンド実行するツールです。言葉では意味がわからないと思いますが以下コマンド例をどうぞ。#  export VARS='{"examplekey1":"value1", "examplekey2":"value2", "examplekey3":"value3"}' のようなJSON形式の文字列を格納する環境変数が設定されている状態で以下を叩く$ json2env --keys "examplekey1,examplekey2" --envname VARS env | grep examplekeyexamplekey1=value1examplekey2=value2JSONの中から環境変数を設定してenvコマンドを叩いているので、envコマンドの出力としてJSONの中の値が出ています。どういうシーンで使うことを想定しているの? なんでキー名を指定する必要があるの？面倒じゃない？ とか JSONは標準入力から受け取ったほうが汎用性が高いんじゃない？  等の疑問が湧いてくるような独特なインターフェースだと思いますがそのような設計にした理由は以下に記載しています。なんで作ったの？ある日、AWSのECSに複数の秘密情報を環境変数で渡したい、という要件がありました。まぁよくある話ですよね。DBへの接続時のパスワードとかなんらかのaccess keyとか。それを実現するためには、Secret ManagerのJSONを格納する機能を使ってJSONの辞書に複数キー入れて、ECSの機密情報を展開する機能でそのキー群を突っ込めばいいじゃんってなったんですが、https://docs.aws.amazon.com/AmazonECS/latest/userguide/specifying-sensitive-data-secrets.html#secrets-considerations Specifying sensitive data using Secrets Manager - Amazon ECS を見る限り、Fargateではsecretsとしてsecret managerの値(JSON)そのままは突っ込めるけど、JSONの中のキー指定をして環境変数に設定することはできないらしい、ということがわかりました。つまり、秘密情報として渡されたJSONの値をアプリケーション側で分解して使う必要があります。Secret Managerとよく対比されるサービスであるParameter Storeを使って一つ一つ秘密情報を格納したり、Secret Managerを使う場合でもJSONを使わず1つ1つ秘密情報を格納すればいいという話はありつつ、私はSecret Manager の1つのSecretにJSONで複数の秘密情報を格納したかった*1ので、以下あるように、jqコマンドを使ってそのままJSONを環境変数に変換するようなものを検索してまずは使い始めました。stackoverflow.comただ、上記のようにシェルスクリプトをかく方法だと以下のような問題が感じられました。パッと見で何やってるかよくわからないコードを、今後同じような要件が発生した際にコピペで増殖させていく必要があるJSONを読んで何か環境変数を設定しているということは分かっても、どういう名前の環境変数を使ってるかが分からないSecret Managerのキー指定での環境変数設定機能は今後Fargateでも対応されるのはほぼ間違いないと思っているため、取り外しが簡単なものにしたいが、取り外す際になんの環境変数を使っているかわからないとパッと見取り外しが心理的に面倒になってしまうだろうな、という思いがあったもちろん上記jqのスクリプトを更にいじるとそのようなことはできるが、色々な箇所でコピペコードを少しずつ編集して使っていく、みたいなことをすると取り外しや今後機能追加したくなった際の障壁となるだろうという思いがあったという話を同僚にしていたら、以下スライド中でfujiwaraさんが述べているような、"隙間家具"的なものが必要なのでは？という提案を受け、作り始めることとした。 speakerdeck.com今回のツールは、上記発表資料に記載されている以下2点を強く意識して作ったものである。本家が隙間を埋めたら捨てられる粒度で作るhttps://speakerdeck.com/fujiwara3/aws-devday-tokyo-2019?slide=11そのうち取り外すものをなぜ作るかhttps://speakerdeck.com/fujiwara3/aws-devday-tokyo-2019?slide=41設計思想上記にも書いたが、このツールは結構独特の設計になっていて、ここではその理由を紹介します。最初は汎用性を重視してJSONを標準入力で受け取る方法を考えていたが、実際に、上記このツールを作った理由となったECSへの組み込みの用途で使おうとしたらイマイチ使い勝手が悪いなと思い、上記のようなインターフェースに変えました。1ヶ月くらい盆栽のように作っていたツールを実際の運用に組み込もうとしたことでもっといいインターフェースに気付いたので設計を変更しようとしている。使うというのは偉大な師である。— でこくん (@dekokun) September 6, 2020 なお、JSONを標準入力で受け取ってコマンド実行するようなものを求めている場合は、以下ツールを使うといいと思います。github.com以下、このように設計した理由の詳細を記載します。後で取り外しやすい設計上記にも何度か記載していますが、Secret Managerに格納されたJSONから、JSONのキーを指定して環境変数経由でECSにわたす機能はすでにECS on EC2には存在するため、そのうちFargateにもこの機能が来ることはほぼ間違いないと感じています。そのため、その機能が実装された暁には、このツールは取り外す、という前提で作っていました。そのために実際に取り外しやすいとはどのような状態か、と考えた時に以下が必要だと感じました。取り外す際の変更箇所が少ない(=導入時の変更箇所が少ない)取り外す際の心理的障壁が少ないそれぞれの要求に対してどのように設計したか、以下に記載していきます。取り外す際の変更箇所が少ない(=導入時の変更箇所が少ない)設計最初のインターフェースの設計は、以下のように、標準出力でJSONを受け取る、というものでした。export SECRET = '{"hoge":"hoge", "fuga":"fuga"}'echo $SECRET |  json2env --keys "hoge, fuga" envhoge=hogefuga=fugaしかしこの設計で実際にECSで動くツールに組み込もうとしたところ、Dockerfileで環境変数を展開し、更にパイプでjson2envにわたす必要があり、DockerfileのCMDをシェルを経由するなどして結構書き換えないといけない、ということに気づきました。具体的な変更方法は、以下のような形でしょうか。変更前CMD ["somecommand"]変更後CMD ["sh", "-c", "echo $VARS | json2env --keys 'examplekey1,examplekey2' somecommand"]もしくは、 echo $VARS |  json2env --keys 'examplekey1,examplekey2' somecommand 相当のことをするwrapperを作ってそのスクリプトをCMDに書く、など。実際にこのように変更すると、取り外す時の変更点が増えて心理的障壁が上がってしまうのではないか、という仮説のもと、以下のように最小限の変更で済むようなインターフェースにしました。CMD ["json2env", "--keys", "examplekey1,examplekey2","--envname", "VARS", "somecommand"]取り外す際の心理的障壁が少ない(取り外しによる影響が見えている)上記の通り、今のインターフェースは、JSONの中のどのキーをexportするか明示的に指定する作りとしています。最初に想定していた設計は、以下のように、特にkeysを指定しなくても動く、まぁ普通に考えるとこうなるよね、という設計でした。export SECRET = '{"hoge":"hoge", "fuga":"fuga"}'echo $SECRET |  json2env envhoge=hogefuga=fugaただ、この設計だと将来このツール取り外す際に、問題が起きやすくなるだろうなと感じました。実際に取り外す際の行動を想像すると、 以下のようなことになるかと思いますECSで対象のキーを設定するように変更する上記コマンド例だと、それぞれhoge, fugaをECSの環境変数に設定するような設定を行うツールを取り外すこの際に、常に "exportされている環境変数は本当にこれだけなのか？何か見落としはないか？" というのが不安だろうな、と想像できたため、環境変数としてexportするkeyを明示的に指定することで、取り外す際に考えなくてはいけないことが明確になる、という設計にしました。悩みというように色々考えてツールを作ったわけですが、以下のような悩みがあります。ツール名、もうちょっと付け方があるような気がする。今のjson2envは名前が広すぎるなぁ。今は環境変数に格納されたJSONしか変換できないので、envjson2env、とか…？？とか悩んでいます。また、そもそもこのツールは色々考えて作ったわけではありますが、考え過ぎでただの不格好なものができてしまっただけなのではないか、みたいな気持ちも少しあります。まぁ、実際に長い年月使ってみることでこのあたりははっきりしてくるのでしょう。開発中の日々について最近、仕事以外のありとあらゆることを1日にちょっとずつ、ただし毎日進めていくことで長い時間をかけて確実に進めていくというスタイルが好みなのですが、このツールの開発もそのような形で進めました。また、このブログ自体もそのような形で書きました。この手法は個人の趣味にはぴったりな手法で、少しずつでも完成に近づいていくのは気分が良いものです。"一旦終わらせる" ということさえできれば。このエントリは、このツールの開発を"一旦終わらせる"ということの宣言でもあります。こうしてまた新しいことに取り組んでいける。嬉しいことです。謝辞id:sfujiwara の https://speakerdeck.com/fujiwara3/aws-devday-tokyo-2019 がなかったらこのツールは生まれなかったでしょう。資料中にある handlename/ssmwrap: Exec command with environment variables loaded from AWS SSM. も参考にさせていただきました。ありがとうございます。上記のECSのちょっとした面倒臭さを共有したら"これ、まさに隙間家具の出番では？" という示唆を与えてくれた id:do-su-0805 には大変感謝しております。golangのCLIの作り方については id:Songmu の以下記事を参考にさせてもらいました。また、その記事の内容を実践するためのレールとして、同じく id:Songmu の Songmu/godzil: A Go Authoring tool も便利に使わせてもらいました。ありがとうございます。Goでツールを量産する僕の方法*1:複数の秘密情報を別々に管理すると設定が複数に散らばってしまうのでなんとなく嫌だったのです。Parameter Storeなら秘密情報を階層型に管理できるので、だいぶマシではあるんですが

JSONが格納された環境変数から、JSONのキーの名前とその値で環境変数をセットするツールを作った

以下エントリでも書いた通り、今年はRustで参加した。1130点くらいだった。dekotech.dekokun.info社内で "Rustで爆死したい人" と募ったら、id:Krouton, id:stefafafan 2名の仲間が集ってくれた。私とKroutonは趣味でRustを書いていたけどRustでWebサービスは一切書いたことがない、stefafafanはRustが初めて、という布陣。感想すごく楽しかった。来年もRustで出たいRustのcompile速度をなんとかせねば事前準備当初はRustで参考実装が出るとは思っていなかったので、とにかく準備が大切だということで毎週3人で集まっては次にやることを決めて、1週間そこで出た宿題をやって、また集まるということを繰り返していた。また、3人で休日1日潰してリハーサルを行った。準備の詳細は以下チームメイトのエントリにある通りstefafafan.hatenablog.com当日やったことローカルPCで動くものを準備していて、それをコピペしつつ当日1時間くらい時間をかけたがうまくローカルでブラウザから動作確認できず不発だった今みたら docker-compose の port の bind の設定が間違ってた初回compileにめちゃくちゃ時間がかかるのでtry & errorがやりづらかったpopularityでsortしつつwhereで絞り込んで25件取得している部分は実はwhereでほとんど絞り込めてないのではないかという仮説のもと、まずpopularityでsortして上から100件を取得し、そこからアプリケーションでfilterして25件に満たなかったらwhere句も付けるようにフォールバックしたら点数上がったテーブルが2つかないしpt-query-digest見てもそれぞれのtableの負荷が高いクエリが同じくらいの数あるしテーブル間でjoinもしとらんなということでDBをサーバ毎に分割したinitializeで、他のサーバのinitializeを叩いてDBの初期化をするようにした最後にメモリキャッシュしようとしたがうまくいかなかったdiff Cache estates のキャッシュ by dekokun · Pull Request #17 · dekokun/ISUCON-2020-qualify · GitHubそもそもどの範囲でデータが共有されるのかよく分かってない。多分私達の実装ではthread毎にキャッシュ構造体をcopyしているので、CSV入稿でキャッシュを飛ばしている部分、1thread分しかキャッシュが飛ばない気がしたこの変更はデプロイしたがエラーが起きるようになって諦めた、人類に、30分でキャッシュ実装を自前で持つのは早すぎると思われた。次回は大人しくserialize/deserializeしつつRedisを活用するということをしたいISUCON後にやったこと3人で振り返りをしたKPTで振り返った本番で不発だったDockerでのローカル開発環境が動くようにした以下、いい気付きもあったDocker環境でRust開発する際にtarget下キャッシュしてるのになぜ毎回crateのDLが走るのか(compileは走らない)と思ってたけどcrateのDLはマシングローバルにキャッシュされるのね。言われてみれば。 / “Cargo seems to download the same crate at least once per package -…” https://t.co/jLLRNyiUXB— でこくん (@dekokun) September 15, 2020 疑問Rustでcompile速度を上げたかったら、crate分割がいいんかなぁ。。。Rustのcompileに数分かかり、デプロイが結構きつかったその他良かったことチームの最初のキックオフでISUCONの意気込みの一つに "アウトプット" を掲げて参加した結果、stefafafanがブログを書いたり、Rustの勉強会のLT発表を申し込んだりして非常に良かったRustのLT会 Shinjuku.rs #12 @オンライン - connpass に皆も参加だ！キックオフのときの意気込みは以下の通り。Kroutonもブログを書いたら(書くって言ってた)、3つの意気込みのうち2つが達成されたということになるので、まずまずなのではないか初期実装がなくてもRustを貫徹する。Rustを信じろ！予選突破アウトプットチームメイトの書いたエントリがめっちゃ味があってよかった。krazy.tokinia.meこれまでのISUCONの記録2013年PHPで予選突破し決勝進出。dekokun.github.iodekokun.github.io2014年PHPで予選突破し決勝進出dekokun.github.io予選のエントリはなかった。2015年PHPで予選落ちdekotech.dekokun.info2016年, 2017年, 2018年, 2019年ISUCONに毎年参加してるのだがエントリがない…確かPerlとかGolangとか使いつつ予選落ち2020年dekotech.dekokun.info

ISUCON に Rust で参加して予選敗退

ISUCONでRustで参加する同胞達や、Rustの参考実装を書く人の参考に少しでもなればとこのエントリを書いてます。（いや実際全然わからないのでもっといいの教えて！ってのもあります。はい。）今年のISUCONはRustで戦います。なぜなら、私はRustが好きだからです。ISUCON、Trust Rustというチーム名で参加登録しました。Rustを信じろ！！！！！！！！！！！！— でこくん (@dekokun) July 10, 2020 しかし、私含めてチームメンバー全員がRustでWebアプリを書いたことがなかったため、毎週ミーティングを行いRustの勉強としてやることを宣言して1週間後に進捗報告をしまたやることを宣伝する、ということを繰り返しています。ただそれだけではチーム全員で動くISUCONの訓練としては弱いので、ISUCONを模したリハーサルをしてみました。お題お題としてはISHOCON2というのを使わせてもらいました。以下理由でISHOCON2を選定しました。ただ、もちろんRust実装なんてものはないので、リハーサルはそれをRustで実装し直すところからスタートです。ベンチマーカー、webアプリ共にAWSのAMIがあるため、事前準備がほぼ0で始められる実際、事前準備15分ほどで開始できた実際にISHOCON2を利用したコンテストが何度か開かれているという安心感ISHOCON2のREADMEに書いてあった1人で解くことを想定してだと思うが普通のISUCONよりも簡単であり、全部を1からRustに書き換えるうちのチームが最初に取り掛かる題材としては適切な難易度に思えるgithub.comRustで再実装するために使ったライブラリ群webアプリケーションフレームワークactix-web実践Rust入門にも載っていたし採用DB接続ライブラリsqlx最初はmysqlを使用しようかと思っていたが、ISUCONでmysqlではなくpostgresqlとかが出てきたらダルいなと思っていたところに、AtCoder Problemsがsqlxに乗り換えようとしている話を見てsqlxについて知り、実際に触って見たら非常に楽でいい感じだったため採用したquery!マクロによるコンパイル時のクエリチェックが異常に優秀。コンパイル時にDBに接続しにいき、SQLの構文及びカラムの存在有無のチェックがされるの大変すごいと思うRustのsqlxのquery!マクロとvscodeのrust-analyzerの組み合わせ、異常に強力だな。環境変数にDBの接続先を入れておけば、書いてるだけでマクロ内のSQLのチェック(構文及びカラムの存在有無確認も)してくれてエラー出してくれる。パネェ。 pic.twitter.com/0SjjvU2uIX— でこくん (@dekokun) August 15, 2020 ちなみに、リハーサルの後にも引き続き実装を進めたが、 SQLの where column in (x, x, x) みたいなの書くのが面倒で既存実装をRustに移植する過程で更に N + 1問題を作り込んだwISUCON-2020-suburi/main.rs at master · dekokun/ISUCON-2020-suburi · GitHub本選までには簡単にできるようにしておかないとテンプレートエンジンteraPythonのJinja2からインスパイアされたテンプレートエンジン当日の進捗皆、Rustでなんとなくエンドポイントの実装ができるようになったが、全然実装は進まなかった。Rustだけ書いていたわけではない(アクセスログの解析や、ローカル開発環境を整えるのに異常に時間がかかった)が、それにしても全然実装が進まなかった。これはやばい、とにかくRustの初期実装が必要だ、と思っていたら、以下でRustの参考実装があるらしいということがわかり、なんとか首の皮がつながった感じがありました。参考実装に応募してくれた皆さんには感謝感謝です(実はうちのチームからも1人応募したけど参考実装者には選出されなかった)isucon.netちなみに、参考実装者誰か出てくれないかという一心でrust-jpのslackに書き込んだらそれを見て応募してくださった方もいるようで、本当にありがたいなと思いました。めちゃくちゃ嬉しかったです。maguroさんありがとうございます！こんにちは！Slackででこくんさんの投稿を見て「おっ、やってみたい！」と思い申し込みフォームから申し込みはしまして、練習のためにisucon9をRustに移植してみてるという状況だったりしますw— 🍣maguro🍣 (@yusuktan) August 11, 2020 書いたプログラム以下リポジトリで実装をしていました。github.comやった感想リハーサルの後にチーム全員で振り返りを行いました。Rustに関係ありそうなところをピックアップします。crateのコンパイルに大変時間がかかるので、必要なcrateは事前に列挙して最初からコンパイルしておくと便利Rustのバージョンを変更させるとcrateがコンパイルしなおしになり大変時間がかかるのでRustのバージョンは事前に決めておいて最初からrust-toolchainファイルで固定しようvscodeのRemote SSHを使ってサーバ上で、rust-analyzerなど使いながら開発するとメモリが3GBほど食われて非力なサーバで複数人が開発すると死ぬローカル開発環境を作りました最後にRustの優秀さを知らしめるぞ！

ISUCONに向けてRustでのリハーサルを実施した。採用したRustのライブラリなど

Next.jsのチュートリアルやった。始めたきっかけとしては、最近社内の複数人のメンターとしての立場があるわけなんだけど、みんなNext.js使ってるんで私もちょっとは触ってみたいなと思ってた、というのと前職の転職前は1~2年くらいガッツリフロントエンドやってたけど現職への転職後5年はインフラエンジニア的な仕事が多くフロントエンドは全く触ってなかったので少し今のフロントエンド界隈の空気を感じたいな、という気持ちがあったところにちょうど以下エントリが流れてきたのでいっちょやってみるか、となったのであった。qiita.com4月末に始めて、毎週土曜日にちょっとだけでもすすめることを意識してちょっとずつ進めたら2ヶ月ほどで終わった。数年ぶりにフロントエンドやるかとnext.jsのチュートリアルを4月末に始めてちょっとずつ進めてたらさっき終わった。— でこくん (@dekokun) July 4, 2020 感想としては、なんか便利な世の中になってるなというところであった。SSRがこんなふうにできる世界が来てるの、みたいな。確かにこれはNext.js便利だわ。みたいな。まぁ私はNuxtの方は全く知らないんだけど。あと、あくまで触りの部分を触っただけ、というか書いてあるコードをコピペして喜んでいただけではあるので、ここから色々な深淵があるのだろうなぁしらんけどというのもある。あと、Vercelへのデプロイは簡単で良かった。SSGについては、"CDNのDはdekokunのD"とか言ってる私としては以下エントリと同様の気持ちに少しなるが、まぁ文中に記載のある "EC2 の IP アドレス直接公開してるような Web アプリ/サイトってよくあるからそこが幸せになると幸せな人って案外多いんだろうか" というところなんだろうなぁ。わからんけど。diary.app.ssig33.com

Next.js のチュートリアルやった

ICFPC2020に1人チームで参加しました。ICFPCってのは72時間ぶっ続けで行われる、チーム組んでもいい国際プログラミングコンテストです。今年はコンテストが始まってから急遽参加を決めたため、1人チームかつあまり時間をかけられませんでしたが非常に楽しかったです。ちなみに、73位ってのは、後半ステージに参加した95チームくらいの中での73位なので、まぁ、そんなに良くはない。icfpcontest2020.github.io概要ICFPC、点数出たね。我らがチームdekokun(私1人)はlightning stageは1ポイントの259位、後半戦は0ポイントの73位でしたな。後半戦1ポイントも取れなかったのは残念だったけど楽しかった、来年も頑張るぞ！— でこくん (@dekokun) July 24, 2020 今年の問題(前半と後半の2ステージ制だったんですが前半はほとんど参加できなかったため後半のみについて書いてます)簡単にいうと、宇宙船を宇宙語を使って操り、1対1の勝負で対戦相手の宇宙船を倒し、地球人最強を決めよう！という感じのものです。こちらのコマンドを宇宙語に変換する/宇宙語をこちらのわかる言葉に変換する方法を学ぶところからスタートしました。最初はひたすら何をリクエストしても宇宙人から "1101000" というレスポンスだけが返ってきて絶望しましたが、宇宙語を学ぶことで意味が分かるようになります。1101000は (0) にデコードされます。コンテストが進んでいくとある程度宇宙語が読める/手で書けるようになってしまい、人間ってすごいなって思いました。 (1) は110110000100 ね。多分。githubのprivate repo(その他privateなgit repositoryならなんでも)にdeploy keyとして運営の鍵を設定し、git pushすることでプログラムが提出できるというシステム、非常に使いやすくてよかったです。私は宇宙語の中でも数値とpair, listのmodulate周りしか使わなかったんだけど、なんかdiscordでの他の人の話を見ていると他の演算も使ってるっぽい？まだまだ私の知らない奥深さがあるのだろうなぁ。前半戦は関数型プログラムを自分で開発するみたいなのやってたみたいですが、前半戦が行われている頃は申し込み前、もしくは子供と2人で遊んでた頃だったので、初回submissionだけして他は何もせずに終わってしまいました、ので正直何も知らないです。最終的な作戦ややったことやってることは非常にダサいのですがまぁこんな感じでやってました。力が足りずゴリ押しで異常な感じのプログラムを書いてしまった…精進したい。プログラム： https://github.com/dekokun/icfpc-2020/tree/submission書いてる言語はRustです。まぁ全くRustらしいコードは書けてないが…。atcoderもRustで出てるし今年のISUCONもRustで出る予定だし、もっとRustたくさん書いていきたい。トークンに1対1に対応するコマンドを打ち込むようなコードを書き、手でトークンを書いてsubmitトークンが宇宙語として正しいかどうかの確認をしていないのでdebugが異常に大変だった宇宙船が真ん中に落っこちないように、velocityの方向への噴射(=velocityの逆方向への加速)をひたすら実施これ以外に色々試したのだがうまくいかなかった。落ちる方向の90度回転した方向に行きたかったんだけどなんかコマンド発行がうまくいかなかった。コマンドは受け付けられてるのになぜか何もしてないことになっているように見えたり、なんか全体的にルールもよくわからんみたいな感じだったサーバからのレスポンスを読む部分は異常なゴリ押しによって達成されたゴリ押ししてるコード： icfpc-2020/main.rs at submission · dekokun/icfpc-2020 · GitHubtwitterでは"コンパイラ書いた経験が活かせそう" とかかっこいいこと言ってたけど残念ながら精進がたりなさすぎて無理だったちょうど私のコンパイラづくりの経験が活かせそうな局面に入ってるし頑張るぞ！！— でこくん (@dekokun) July 20, 2020 弾を打つこともできなかったし敵の位置を捕捉することもできなかった。全体的に隠しパラメータの意味は何一つわからなかった。ここらへんは時間の足りなさ、一人でやることの弱点が強烈に出たなと感じた。Discordの英語でのやり取りの流れも全然追えなかった来年に向けて今年面白かったし来年もぜひ出たい！来年は複数人で出たいし、もっと事前に家族・仕事の予定を押さえておきたい。1人で参加するのは相談相手もいなくて大変だし、妻が家におらず子供を見ながらプログラムを書くこともできない、また、当日になって午後休をとって会社には申し訳なかった。事前に休むことにしておけば良かった。今年はローカルでのテスト方法を確立できなかったのは非常に開発の足を引っ張った。来年はそのあたり整備したい。謝辞"ようやく宇宙船の動かし方が分かった！しかしもう仕事だ…" と諦めてた月曜日、同僚から背中を押されて午後仕事を休んでICFPCに打ち込みました。感謝です。来年は、しっかりと事前に調整して会社を休もうと思います。ICFPC、同僚の勧めもあり、午後はまるっと仕事せずに参加することにしました。はてなという会社は良い会社です。— でこくん (@dekokun) July 20, 2020 時系列(日記)途中からリアルタイムで書いたら日記みたいになった。2020/07/19 15:00 子供が寝た時に思い出して参加登録。すでにコンテスト開始から17時間が経過しておる。妻がおらず私と子供と2人だけで過ごす日だったので全く手につかない。昼は諦める2020/07/19 21:00 子供が寝たので再開。Lightning Roundがいつの間にか終わってたのに頑張ってた。APIのレスポンスの意味が何もわからん〜ってなってた。眠すぎたので寝る。2020/07/20 午前 消防団の会合に参加。チェーンソーを扱う、消防団でチェーンソーの練習してる。— でこくん (@dekokun) July 19, 2020 2020/07/20 午後 眠すぎたので昼寝。子供と遊んだりしながらちょっと問題見るが意味不明すぎて困る。コマンドを送信してるはずだがサーバからは同じレスポンス(エラーなのかもわからない)が返るだけだなぁ2020/07/20 21:30 子供からも解放され問題をよく読んだりDiscordでのやり取りを見てようやく意味がわかる。コマンドをmodulateしないといかんのや！しかし明日は仕事なので寝ようとする2020/07/20 00:00 目が冴えすぎて寝られない。PCの前に座って再開。2020/07/20 00:50 submission成功！ついにスコアボードに載る。世界で53位だ！とか言って喜ぶ。仕事がやばいので寝ることにする。ICFPC、頑張ってたらようやくスコアボードに載った。世界で53位だ。(なお参加者数は300チームくらい、そのうちの大多数が脱落してると思われる…私も脱落しかけたがなんとかかんとか… https://t.co/rG4mb2nys6— でこくん (@dekokun) July 19, 2020 2020/07/20 01:43 寝ることにするといいつつ寝られなかった。スコアは最下位付近を動いている。初期値をランダムな値にするようにしてみた。2020/07/20 02:12 visualizerで見られる他の人のパラメータを真似して使ってみた。意味は全然わからない。コマンドはなぜか通らなくて困っている。2020/07/20 2:20 よるおそすぎるので寝る。こんなに遅くまで起きてたの数年ぶりとかだと思う。しかしvisualizerの使い方が全くわからない。なんだこれ。初期値だけ見られる状態。2020/07/20 2:33 といいつつまだ起きてる。やばすぎ。なぜかコマンド通らないのでshootにしてみる2020/07/20 3:29 まだ起きてる…明日会社行けるのかな…布団で携帯でドキュメント見てたらcommandsがcommandのリストだと気づいてしまったので修正してpushした2020/07/20 6:30 起きて見てみたらまだ落ちてた。辛い。コマンド変えてみた。discord見ても同じようなことやってる人いるなと観測w。ちょっとコマンドを変えて提出してみたらついにコマンドが通ってちょっと勝ち始めた。visualizerが動いてなかったのは、ただ単にコマンドが正常に発行できてなかったので1ターンも経過せずに静止画になっていたからだった…まだ初手で自爆することしかできない。自爆コマンド以外は受け付けられない。2020/07/20 9:00 子供を保育園に預けた後に再開。本当はめっちゃ眠いから寝ようと思っていたんだが、面白さに勝てない。2020/07/20 10:00 仕事開始直後に、Consを使ったvector指定で自爆以外のコマンド実行に成功した！最低限やりたかった第一段階クリアだ！仕事せずにやり続けたい！！！次はサーバからの返り値を解析する部分だ。しかしもう仕事で時間がない…2020/07/20 14:00 同僚の勧めで午後は仕事を休んで参加している。サーバからの返り値を解析する部分だ。2020/07/20 15:30 サーバからの返り値の01を解析できたと思ったが、実際に来ているのはbytes::bytes::Bytesとやらでこれを01のままStringに直す方法が分からない…厳しい。しょうがないのでformat!からdebug出力を拾ってsliceで頭の b" とお尻の " をとった。ダメでしょこれw2020/07/20 16:00 眠すぎて30分仮眠2020/07/20 16:27 起きた。サーバのレスポンスを、決め打ちで解析する作戦にしよう2020/07/20 18:05 私は何をやっているんだろうと思いながらモクモクとひたすら黙々と決め打ちのデバッグ作業をしている2020/07/20 18:25 ついにサーバレスポンスを利用する変更が動いた気がするのでpushして試そうとしている。しかし、結局隠しパラメータの意味がぜんぜんわからない。デプロイ時間を利用して他の人の対戦を参考にしてみよう。2020/07/20 18:39 他のチーム見たら、なんかspaceshipが複数機いるんだがwwwワロタwwww私は1体しか使えないのにwwww何が起きてるのか全くわからない。。2020/07/20 19:00 妻が出かけるので子供の面倒をみるために一時離脱。子供の面倒を見る間にちょこちょこはコードを触るがあまり思考できない。2020/07/20 21:30 子供がめっちゃ泣いてなかなか寝なかったがようやく寝てくれた。あと30分で何をするか。2020/07/20 22:00 いくつか変更を加えて自分と戦わせるが全然弱いので提出物には変更を加えずにおいておくことになった。結局何が起きてコマンドが途中から発行できなくなるのか全然把握できずに終わったな〜

ICFPC2020に参加して73位だった

Qualificationは突破したのでRound 1に参加したけど3833位なので残念ながらRound 1は突破できなかった。解けた問題2問目のOverrandomized だけすべてのテストセットを突破した。ベンフォードの法則を偶然知っていたので解けた。ベンフォードの法則を知ってると、極めて簡単な問題で、1文字目の出現頻度を全部計算して多い順に並べていく(1文字目以外には出現してるのに1文字目には1度も出現してないものは0にマッピングする)という感じで解けた。プログラムは以下の通り。github.comベンフォードの法則は確率的な話ではあるが、10000テストケースあれば十分な個数である。もし運悪くWAが出た場合は8と9を入れ替えたりしつつ全部試していくみたいなことをすればよかったのだろう。ベンフォードの法則についてはwikipediaでどうぞja.wikipedia.org反省Overrandomizedだけ解けた時点で、開始してから1時間15分、1298位でなんかこれはもしかして予選突破できるのではないかという色気が出て、あとは部分点を稼ごうみたいな思考になった。C問題の最初のテストケースを見るとDが2か3ではないか！ということでif文を量産したけどなんかWAが取れずに死んだ。最初からCを全部解くつもりのマインドで戦ったほうが高得点が取れたと思う、というか部分点狙いだけでは絶対に予選突破できなかった。1時間15分で、1298位で余裕がない(予選突破できるのは1500位)にも関わらず部分点で勝とうとしたことが今から思えば甘すぎる。嬉しかったので撮ったスクショ。ここからひたすら順位が下がるばかりであった。。。感想運良くベンフォードの法則を知っていて得点につながったにも関わらず予選突破できなかった。また来年次のラウンドに進むためにはさらなる精進が必要であろう。頑張ろう。

Google Code Jam Round1C参加して落ちた

人生は勉強である。子供ができてからというもの、自分の人生と向き合うことが増えた。その結果、やりたいことがたくさん溢れ出してきて、子育てによって圧倒的に時間がないながらも、子育て前に比べて圧倒的に学べることが増えたと感じる。勉強に勉強を重ねて人生をより豊かにすべく、日々を送っている。そんな私の勉強方法をここに記す。以前以下エントリにまとめた日々の勉強方法の工夫部分を、それから今までのアップデートも含めて更に増強したのが本エントリである。dekotech.dekokun.infoやりたいことをオーバーラップさせる人間というのは欲張りなもので、費やせる時間に対してやりたいことはいつだって多い。私はコンピュータサイエンスも学びたいし(参照：コンピュータ・サイエンスやりたくなって1年ちょっとコツコツやってる/やったことたち - でこてっくろぐ ねお)、第三次世界大戦に備えるべく英語も学びたい(第三次世界大戦勃発に備えてやっていること - でこらいふろぐ)。小説の三体三部作を全部読みたいし、たまには資格を取ってみたりもしたい。それらを如何にしてオーバーラップさせて単位時間あたりに複数のことを一気に学んでいけるかが重要だと感じている。最近は小説の三体を英語で読んでるし、プログラミングコンテストに参加する際は英語で参加するし、AWS Certified Solutions Architect Professionalの資格の勉強は英語の動画を観ることで英語の勉強と同時にしえちた。このように、如何に物事をオーバーラップさせるかを常に考えていきたい。ただし、私はまだそこまでうまくいっているとは言えない。上の例を見るとわかるが、全部、ただ英語とオーバーラップしてるだけである。英語はたしかにオーバーラップさせやすい。英語以外でも複数のやりたいことをどうオーバーラップさせていいくか。それが今後の課題である。コツコツ続けるための仕組みとにかく子供がいるとまとまった時間をとるのはかなり難しいため、1日ほんの少しでいいからターゲットを決めてコツコツ進めていく、ということを大切にやっている。コツコツと続けるためにはコツがあり、その工夫は色々としているが、私のコツコツする際の思想の骨子は以下エントリにかかれている通り。nhiroki.jp"カンバン仕事術" という本に書いてあると id:Songmu さんに教えてもらった始めることを終わらせ終わらせることを始める という言葉がとにかく気に入っている。アウトプットしたいことが多すぎて時間が追いつかない。時間もまとまった時間は取りづらい、そんなお悩みをお持ちじゃありませんか？？？しかしそういう場合でも “始めることを終わらせ終わらせることを始める” を徹底すれば…！！！なんと、…！！！！！終わっていくのです！これはすごい！！！— でこくん (@dekokun) March 20, 2019人生は長い私には何しろ日々の子育てその他家事が待っているため、まとまった時間を取ることができない。そんな私が何かを学ぶには、とにかく日々ちょっとずつコツコツコツコツと長い期間をかけて学んでいかねばならない。しかし、勉強をしていると、どうしても目先のことばかり考えてしまいがちである。"勉強しようと思った分野ちょっとやったけど時間かかりそうだとわかったしやはり別の何かをやろうか" のような。しかし、そこで、人生の長さを考える。私は今33歳。多分あと40年くらいは仕事をしそうだし、死ぬまではあと60年くらいありそうである。そう考えると、 "まぁ、すぐに芽が出なくても10年後くらいに役に立てばいいか" という気持ちになり、時間がかかりそうだと諦めかけた学びもコツコツと継続することができるようになる。かなり人によるだろうなぁこれ。もちろん、学びのために必要な目先の人参がある場合は積極的に使っていくべきである。ここで私が言いたいのは、あくまで "目先の利益がないから学ぶのをやめる" ということはしたくないということであり、もちろん、10年かけて英語を学ぶための今の起爆剤としてTOEICを申し込んでやる気にさせる、というような動きは積極的にしていきたい。Ring Fit Adventureやっていたら 長期目標は高く、短期目標は低く と言っていて、そうそうそれそれ感あった。やることを書き出し日々メンテするTodoistに日々やる細かいことと勉強したいことを繰り返し予定で全部入れ、それが全部達成できることを狙って日々過ごす。しかし、睡眠時間のほうがより重要なので、終わってなくても寝る。終わってない日々が続く場合はやることを減らすなど、無理のない範囲でできるようにメンテナンスする。特に、TODOにはめちゃくちゃ取り掛かりやすい、脳死でもできることを書いておくのが重要で、例えば私が先日AWS Certified Solutions Architect Professionalの資格を取得した際は、毎日AWSの各サービスの動画を観ることにして、動画のURLをTodoistのタスクとして突っ込んでおき、1クリックだけで学びが開始できる状態にしておいた。また、特に動画を観る時間のノルマを決めず、一瞬でも見ればその日はOKとした。そうすると、やる気がなくても1クリックで学びが始められ、一度始まるとやる気に繋がることも多々ある。やる気につながらなかったらとっととやめて寝るべきである。不要なことをしない毎月、今月やらないことを決めてそれを徹底している。例えば、 今月は一切マンガを読まない 今月ははてブはテクノロジーカテゴリ以外読まない など。それを毎月積み上げていっている。以下TED動画で、今月やることやらないことを決めて徹底しろと言っており、この動画を一時期ひたすらシャドウイングしていたこともあって頭に完全に刷り込まれた。www.ted.comまた、今やっていること以外でも これやりたいな というのは日々出てくるものであるが、やりたいと思ったことは全部spreadsheetに作成したやりたいことリストに順位付けして放り込んでいる。将来これを頭からやっていくぞ！ と思うことでだいぶやりたい心が抑えられる。しかし全く実現の気配がないようだとそのうちに意味がなくなってくると思われるため、日々のTODOをすべて解消した時になんでもできる時間として、エンペラータイムというものを導入した(参考： 絶対時間(エンペラータイム)というのを生活に導入したらいい感じになった - でこらいふろぐ)。エンペラータイムでは、もっぱら上記やりたいことリストに放り込まれたやりたいことをしている。また、当然ながら、本当にやりたいことは、やりたいことリストには入れず、分解して日々のTODOに突っ込んでいっている。ディープライフ日々大変細切れの時間しか取れないため、ディープライフを意識してやっている。以下の発表資料読んで、 私も子供と目一杯遊ぶぞ！ という気持ちになれ、発表者のmatsumotoryさんには大変感謝している。speakerdeck.com最後にそんな感じで、日々私は学びを続けており、これだけ日々継続して色々できてたら今後楽しい人生送れるだろうなぁと結構ワクワクした日々が送れているのであった。めでたしめでたし。以前書いた、日々コツコツ学ぶための勉強法が更に進化を遂げたのでどこかで書いておきたいなと思っていたらちょうどお題キャンペーンで 私の勉強法 というのがやっていたので書いてみた。 私の勉強法 というにはこのエントリの内容はちょっとメタかもしれないが、まぁ全く外れているわけでもなかろう。(2020/01/17 追記)更に考えると、勉強法というよりは、やりたいことをどうやっていくか、という感じの内容だなぁと思った。私の場合はやりたいことの大半が、世間で言うところの "勉強" にある程度一致しているのだなぁということも感じた。はてなブログ特別お題キャンペーン ＃学び応援WEEKギノ

子育てしながら人生を賭けてちょっとずつやっていく、私の勉強法

このエントリは RecoChoku Tech Night 5社合同 AWS re:Invent 2019 参加報告会 - connpass での発表内容、及びはてなエンジニア Advent Calendar 2019の20日目のブログ(若干フライングで投稿しています！)です。 AWS re:Inventのセッションの一つである SVS323-R1 - REPEAT 1 Mastering AWS Lambda streaming event sources を元ネタに、re:Invent 2019直前に出たKinesis Data Streamsの新機能の解説をします。基本的な用語説明Kinesis + Lambdaの活用事例Kinesis + Lambdaのスループットが思ったように出ない時、及びその対処方法シャードを増やすのは万能なのか？他の手はないのか？新機能のご紹介シャードを増やすことの問題上記の悩みを解決する新機能のご紹介デモParallelizationFactorを増やすことの注意点最後に免責最後の最後に基本的な用語説明このエントリを読むのに必要な最低限の用語を解説します。詳しくはAmazon Kinesis Data Streams の用語と概念 - Amazon Kinesis Data Streamsが画像、内容共に参考になります。Kinesis Data Streams はシャードの集合です。AWSのサービスとしてのKinesisにはData Streams以外にも色々なサービスがあるのですが、このエントリでは特に誤解の懸念はないため、以下 Kinesis と呼びます。Kinesisに投げ込まれるデータ1件1件のことをデータレコードと呼びます。データレコードをKinesisに投げ込むのは プロデューサー です。シャードが複数ある状態でデータレコードがKinesisに挿入されられると、データレコード内にある パーティションキー を元に、各シャードにグループ分けされます。Kinesisに投げ込まれたデータは、コンシューマが取得して処理します。このエントリではコンシューマがLambdaである場合について記述します。シャード1つ1つに対して読み取りや書き込みのスループットに関する制限があり、また、Kinesis + Lambdaの場合、1つのシャードに1つのLambda関数が実行されるというモデル(このエントリで紹介する新機能の前の話ですが)であるため、性能を上げたい場合はシャードを増やす、というのが基本的な戦略になります。シャードとLambdaの並列度あるデータレコードがKinesisに投げ込まれてからLambdaによって処理されるまでの時間は、CloudWatchでLambdaの IteratorAge として確認することができます。IteratorAgeが上がった場合、一般的には投げ込まれるスループットよりも処理するスループットが少ないことが多いのでIteratorAgeはどんどん上昇していくことになります。IteratorAgeちなみにこのエントリではKinesis + Lambdaについて語っていますが、ほとんどそのままDynamoDB Streams + Lambdaにも当てはまります。Kinesis + Lambdaの活用事例AWSの導入事例でも、Kinesis + Lambdaを、スケールするデータ分析機能の一部として使っている事例が紹介されています。Bustle Case Study - Amazon Web Services (AWS)はてなでも、 時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ にあるように、Kinesis + Lambdaの構成はバリバリ使っています。Kinesis + Lambdaのスループットが思ったように出ない時、及びその対処方法Kinesis + Lambdaの構成を実際に運用していると、思うようにスループットが出ない、つまりKinesisに投げ込まれたデータ量に対して出口のLambdaの処理量が足りなくなり、Lambdaが処理していないデータがKinesis内にどんどん増えていく状況が起きる場合があります。どのようなときにそのようなことが起きるのでしょうか。インターネットに書いてある事例や私のみたことのある事例や私の想像力から、以下に起きそうなことと、その対処方法を以下に列挙します。この列挙と対処法ついては Lambda 関数の IteratorAge メトリクスを下げる に書いてある内容を大いに参考にしています。Lambdaの同時実行数制限を超えてしまい、Lambdaの実行にスロットリングが発生するLambdaの同時実行数制限を上げましょうLambdaが特定のデータレコードに対してエラーになり、そのデータレコードが生きている間(デフォルトでは24時間)延々と同じデータレコードの再試行を続けて全くデータの読み取りが進まなくなる対象のデータレコードが来てもLambdaがエラーにならないようにLambdaを修正してデプロイしましょうもしくは AWS Lambda Supports Failure-Handling Features for Kinesis and DynamoDB Event Sources に書いてあるようなLambdaのエラー周りの新機能をうまく使って回避しましょうこちらも実はre:Invent直前に出た新機能です。エラーを無限に再試行しないような設定をしたり、エラーが発生したら1つのLambdaが受け取るデータ量を減らして再試行したりすることができるようになりましたKinesisのコンシューマーが複数存在する際に、コンシューマーが1つのシャードからデータを読んでくることでシャードのスループット制限を超えてデータが読めなくなるKinesisの拡張ファンアウトを使う、もしくはシャードを増やして1シャードあたりのスループットを減らしましょうそれぞれのLambda関数が1つのシャードからデータを読みシャードの読み取りスループット制限を超える。分かりづらいかもですが、それぞれのLambdaが同じデータをそれぞれ読み込んでいますコンシューマーであるLambdaが遅すぎて1shardに入るデータ量よりもLambdaが処理するデータ量が少ないLambdaで行われている処理に対してCPUリソースが足りない場合は、Lambdaのメモリを増量することでCPUを強化できるのでしましょう。もしくはシャードを増やすことでデータ量あたりのLambdaの実行数を増やしましょうLambdaで行われている処理以外に時間がかかっている場合(ex. sleep, 外部のネットワークへのI/O等)は、シャードを増やすことでデータ量あたりのLambdaの実行数を増やしましょうシャードを増やすのは万能なのか？他の手はないのか？新機能のご紹介シャードを増やすことの問題上記で、シャードを増やす、という解決策がいくつか出てきます。実際Kinesisはシャードを増やすことでだいたいのスループットの問題は解決するのですが、ここで1つ大きな問題点があります。それは、詰まってる状態でシャードを増やしてもシャードが増えた効果はすぐには発揮されないということです。以下で詳しく解説します。Kinesisのシャードを増やすというのはどういうことかというと、1つのシャードを分割することを意味します。分割する前のシャードを親、分割した後のシャードを子と表現します。Kinesisにおいて1つのシャードを2つに分割すると、それ以降に投げ込まれるデータレコードは新しい2つの子シャードに入っていくのですが、すでにKinesisが親シャードで受け取っていたデータは親シャードに残り、1並列でLambdaが処理することとなります。親のシャードのデータレコードがなくなるまでは並列数は増えないすなわち、投げ込まれるデータレコードのスループットよりも処理されるデータレコードのスループットが少ない状態で時間が経過して、lambdaで処理しているデータレコードが、x時間前にKinesisに入ったデータだった場合(=LambdaのIteratorAgeがx時間)、シャードを増やしたとしてもx時間経過して親シャードのデータがすべて読み取られるまでは遅延が続くことになります。参照： リシャーディングすると、親シャードに流れていたデータレコードは、データレコードのパーティションキーがマッピングされるハッシュキー値に基づいて、子シャードに流れるように再ルーティングされます。ただし、リシャーディング前に親シャードにあったデータレコードはすべて、それらのシャードに残ります リシャーディング後 - Amazon Kinesis Data Streams参照2： 注意 : シャードを分割しても、イテレーターの経過時間には直接影響しません。既存のレコードは書き込み先のシャードに保たれます。これらのシャードがバックログに追いつくと、それらのイテレーター経過時間は短くなります。対応するまでに膨れ上がったIteratorAgeの時間が、シャードを増やした後にKinesis + Lambdaの遅延が解消するまでの時間にそのまま直結するため、素早い復旧のためには如何に遅れを素早く検知してシャードを増やすかが重要になってきます。IteratorAgeを見つつシャードをオートスケールさせるのが解の一つなのかもしれませんが、Lambdaの更に裏側のなにか(DBなり外部APIなり)が詰まる可能性も考えると、オートスケールさせるのも少し不安になりますね。かといって人間が対応しようとすると、普通の障害以上に、如何に早く検知して早く対応するかの戦いになってしまいます。大変ですね。もちろん、Kinesis + Lambdaの構成はそもそも非同期であるため、少しの遅延が即座に問題になるわけではないようにシステムを構築するのが基本ではありますが、いくら遅延が大丈夫と言っても数分の遅延は許せるが数時間の遅延になってくると問題になるケースは少なくないのではないでしょうか。上記の悩みを解決する新機能のご紹介今回の問題は、Lambdaの並列数を増やすためにはシャードを増やすくらいしかないが、シャードを増やすしても効果が出始めるのは問題が発生し始めてからシャードを増やすまでの時間だけかかってしまうということでした。何か、対応したらすぐに効果が出る方法はないものでしょうか。ということでre:Invent2019直前に発表された新機能のご紹介です。AWS Lambda Supports Parallelization Factor for Kinesis and DynamoDB Event Sourcesです。これはなにかというと、これまでできなかった1シャードあたりのLambdaの実行数を増やすことができるという機能となります。これによって、シャードを増やさなくてもLambdaの並列数を増やすことができるようになります。それでは、本当にこの機能によって、これまでの シャードを増やす という対応策では実現できなかった、すでにKinesisのシャードに投げ込まれたデータの処理の並列数を後から増やすことはできるのでしょうか。以下デモをご覧ください。デモRecoChoku Tech Night 5社合同 AWS re:Invent 2019 参加報告会 では以下をデモします。このブログを読んでいる皆さんも以下を参考にデモをしてみることが可能だと思いますので一度やってみてください。以下をcloneし、README通りに環境を設定し、make put_records まで実施してKinesisにデータを投げ入れます。github.comその後、template.ymlを編集して2つあるLambdaのうちの片方のParallelizationFactor部分を2以上に増やし make deploy して待つと、CloudWatch上の、ParallelizationFactorを増やした方のLambdaのIteratorAgeの上限がもう片方と比べて下がるのが確認できるのではないかと思います。このデモでは、1シャードのKinesisに1件のレコードを取得し毎回1秒スリープするLambdaが付与されておりそこに1000件のデータを流し込んでいるので、ParallelizationFactorが1だとIteratorAgeは1000秒付近になりますが、ParallelizationFactorを増やすとその分IteratorAgeの上限が下がっているのがわかるかと思います。デモ事前に私の手元で実施した環境でのそれぞれのIteratorAgeの推移(サーバ管理ツールMackerelで取得)は以下のとおりです。グラフが途切れてる部分が処理完了を表しています。以下グラフの時刻が同じ時刻になってるのを見るとわかると思いますが、1つのKinesisに対して2つのLambdaをコンシューマーとして登録し、片方のLambdaのParallelizationFactorを増やしています。ParallelizationFactor: 1 で全レコード処理するのに1000秒かかってる様子(単位: ms)ParallelizationFactor: 1ParallelizationFactor: 1 を ParallelizationFactor: 10 に変更して200秒ほどで全レコードが処理されている様子ParallelizationFactor: 1 -> 10ParallelizationFactorを増やすことの注意点Lambdaの並列実行数が増えることになりますので、Lambdaの並列実行数制限には注意しましょうシャードを増やす時同様、Lambdaの更に後ろにあるサービス(DB, 外部API, etc)がつまらないかどうかには注意しましょう最後に以上、AWS re:Invent 2019の直前に発表されたKinesisの機能の紹介でした。そんなに派手な機能ではないと思いますが、切り札の一つとして持っておくといいのではないかなと思います。本エントリへのツッコミなど激しく募集しています免責この実験情報はあくまでも私の環境で行ったもので、あまねくどの環境でもそのようなことが起きるかは不明です。本番環境で使用する前にAWSのサポートに問い合わせていただけたらと思います。最後の最後にはてなエンジニア Advent Calendar 2019ですが、前日は id:Pasta-K さんのウェブページの表示を遅くなくしたい時の道標 - ぱすたけ日記でした。明日は id:papix さんになります。

Kinesis Data Streams + Lambdaが詰まった時の対処法(RecoChoku Tech Night 5社合同 AWS re:Invent 2019 参加報告会 登壇資料)

dekolife.hatenablog.com上記エントリを書いたりしたあと、無事に会社によってAWS re:Inventに行かせていただけることになりまして、上記から更に英語修行を重ねつつre:Invent行ったわけなんですけども、英語がびっくりするほど聞き取れなくてびっくりしました。体調や話者による、聞き取れる聞き取れないの差がめちゃくちゃ激しいネイティブ同士での会話は全く聞き取れない適当なメンバーでチームを組んで半日くらいISUCONみたいなやつをやるイベント(AWS GameDay)に参加して、ネイティブ3人とチームを組んだのですが、本当に何も聞き取れなくてかなり衝撃を受けた以下、当時の会社のslackの私の悲痛なつぶやき。英語ネイティブ３人に囲まれ最初に「えいごにがてだぜ」と言ってはおいたが完全に置いてかれて現状がわからないまま「何ができる」と話して何度か仕事をもらい、途中で問題を発見するも適切に伝えられず（ここでの押しがもっと必要だった！しかし皆の会話がわからなさすぎてもう知ってるかどうかもわから無い状態で伝え方がかなり曖昧になってしまった）、という感じであった。これは第三次世界大戦、英語経由で生き延びる確率は勉強始める時と比べてほとんど上がってなさそうと感じた。re:Invent前にDMM英会話ちょっとやってたけど、もうちょっとDMM英会話(その他会話)の勉強の割合を増やしたほうが良かったかなと思ったりした。まぁ、純粋に勉強時間が足りてないというのも大いにあるであろう。今後も継続継続。また次海外出張行く時もしくはその他のなにか(ex. 第三次世界大戦) に向けて頑張っていこう！

英語思ったより聞き取れなかった(AWS re:Invent帰り

閾値どっちでもいいのだけど、私は自分が聞き取りやすいので "しきいち" を好んで使います。以上、自転車置き場の議論でした。

いきち、しきいち

最近Atcoderのコンテストによく参加してるのですが、優先度付きキューにお世話になることが異常に多く、内部をちゃんと知っておきたいという気持ちから自前実装することにした。実装は以下です。ほぼ初めてRustでまっとうなものを書いたという感じなので、なんか指摘とかしてほしい。https://github.com/dekokun/atcoder-rust/blob/master/abc141_d/src/main.rs#L25-L141Rustの標準ライブラリの優先度付きキュー(BinaryHeap)はfloatが扱えない(BinaryHeapはOrdを要求するが、floatはNaNの存在のためOrdではなくPartialOrdとなるため)というのもあって競プロ的には使いづらいのでそこも使いやすくしたいという思いもあった。(この目的だけだったらNaNが入らないようなOrdなfloatをつくったほうが筋がいいと思うが今回はBinaryHeapの実装のしたさが先に来ているので。NaNを除くような実装は ordered_float - Rust などが参考になる)実装の工夫や楽しかったことなどコード： https://github.com/dekokun/atcoder-rust/blob/master/abc141_d/src/main.rs#L25-L141優先度付き待ち行列 を参考に作りましたBinaryHeapの実装を知らずに使っている時は"常にソートされているものから値を取り出している"というマインドセットだったが、実装してみると、ソートされてるわけではなく、常に一番上を取ることに特化してるデータ構造だとわかって感動したPartialOrdのpartial_cmpがNoneを返すような比較をしたらpanicするようにすることで、意図せずNaN的なものが混入しても早期に気づけるようにした比較した際にはじめてpanicするため、NaN1つの混入では気づかなくてその後2つ目を入れたタイミングでpanicしてわかりづらさがある。本当は自分自身とpartial_cmpしてNoneが返ったらpanicさせるような実装のほうが好ましいかもしれないが、それはfloatのNaNだけを狙い撃ちにしている感じがしてPartialOrd一般に対する話では無い気がする？など迷いが生じて一旦こうしているstd::fmt::Formatter - Rust を見つつDebug実装を書いたのだけど、Rust 2018 editioinじゃないRustのバージョン(というかatcoderで使用されている1.15.1)ではコンパイルが通らず調べていたら2018 editioinから'_, the anonymous lifetime - The Edition Guide というのが入ったのを知ったRustのVecにはswap_removeswap_removeという、任意のindexの値をVecの末尾の値と交換しつつ取り除いてreturnするという、binary heap実装にうってつけのメソッドがあって便利だった標準ライブラリのBinaryHeapと比較して、手抜きでpopでIteratorを表現しているため、Iteratorが回るとすべての要素がなくなるという感じでIteratorが極めて使いづらくなっているという重大ポイントがある。これはそのうち直さないと厳しい気がしているこの挙動であればwhile let v = binaryheap.pop() みたいな感じでiteratorの代わりになるので、Iteratorを実装しないほうが変な間違いを生まず世のため人のためかもしれない標準ライブラリとの速度比較と実装比較自前実装は標準ライブラリの実装と比較して遅いAtcoderで提出してみると、標準ライブラリ実装は50ms, 私の実装を使うと60msって感じで20%ほど遅い標準ライブラリ： https://atcoder.jp/contests/abc141/submissions/7592976自前実装： https://atcoder.jp/contests/abc141/submissions/7592952BinaryHeapに値をpush/popする際に、親と子の値を入れ替える必要があり、私の実装でははVecのswapを使っている。標準ライブラリでは高速化のため、unsafeな構造体を使ってその中で色々なチェックを省きつつやっていることがわかったHoleという構造体を使うことでswapをせずに済ませている。swapの中では配列の境界チェックを行いつつ、tmp変数を使って2回コピーして、みたいなことをしているが、Holeを使うことでコピーを1回だけにしていたりget_uncheckedを使用して配列の境界チェックを防いだりしている感想自分の実装と標準ライブラリの実装や速度を見比べるのめっちゃ楽しい。今後もお世話になるデータ構造は自前実装していきたい。

Rustの標準ライブラリにある構造体(BinaryHeap)を自前実装してみた

私は経済学部出身でWeb系エンジニアをやっているわけだが、コンピュータ・サイエンスはずっと学びたいと思っていた。そんな中、Turing Complete FMというpodcastに出会ってその気持ちが更に強くなり、ここ1年くらい、子育ての合間にコツコツコツコツとコンピュータ・サイエンス周りのことを学んでいた。このエントリでは、学んでいたこと、及び子育ての合間にどうやって時間を捻出しているのかをまとめた。目次：やっている/やったことコンピュータサイエンス系のPodcastを聞くコンパイラを書く(ペンディング中)OSの作り方を学ぶRustでOSを書く(ペンディング中)Rustを学ぶプログラミングコンテスト系のサービスをやってみるLeetCodeAtcoder計算理論の初歩を学ぶ白と黒の扉を読む大学の教科書で使われているような書籍で学ぶシステムのパフォーマンスについて知る続けるための仕組みやることを書き出し日々メンテする不要なことをしない最近の1日ディープライフ蛇足やっている/やったことコンピュータサイエンス系のPodcastを聞くTuring Complete FMが私のコンピュータ・サイエンス熱を燃やしてくれたpodcast。全部のエピソードを2~3回ずつくらい聞いた。"低レイヤの話めっちゃ面白いな" と、やる気がかなり出るのでオススメ。聞き始めた頃は内容のほとんどが理解不能だった。以下に紹介しているpodcastのMisreading Chatもそうだが、何度も聞く、及びこのエントリに書いているいろいろなコンピュータ・サイエンスの習得の努力を行うことで、どんどん内容が分かるようになっていくのが最高に楽しいのであった。turingcomplete.fmTuring Complete FMの更新が止まってしまったので最近はMisreading Chatをよく聞いている。2回ずつくらい聞いた。たまに関心のない分野のものがあるのでそれは飛ばして聞いている。2人の掛け合いが大変楽しい。心が安らぐ。misreading.chatなお、英語のコンピュータ・サイエンス系のpodcastも聞きたいと思いチャレンジしたのだが、私の英語レベルでは全く聞き取れなかったため、もっと簡単な、コンピュータ・サイエンス関係なく英語を学ぶためのpodcatも1日時間を決めて聞いている。コンパイラを書く(ペンディング中)コンピュータ・サイエンスを学ぶにあたって何か手近な題材ないかなと思っていたら、上記Turing Complete FMの提供者であるRui Ueyamaさんがいい感じのチュートリアルを出してくれていたので(正確な動機はProgramming系のyoutuberになりたくて動画を探したら見つけてRuiさんの作ったものだったし興味範囲にも合致していたからやり始めた、という感じだけど、まぁそこはどうでもよい)、Cで書かれているチュートリアルの内容を当時興味があったRustに置き換えて一つ作ってみた。手軽に言語が動いて楽しかった（これはコンパイラではなくインタープリタだけど）。dekotech.dekokun.infoそして、Rui Ueyamaさんが低レイヤを知りたい人のためのCコンパイラ作成入門を執筆し始めたので、それを追って一緒にコードを書いていた。一時期更新が止まっていたのでそこで私の実装を止めていたら最近一気に加筆修正が進んでおり、だいぶ置いてかれてしまっている…www.sigbus.infodekotech.dekokun.info私の書いてたコードは以下github.com低レイヤを知りたい人のためのCコンパイラ作成入門、これまでBNFで書かれていた部分がちょっと分かりづらかったが、最近EBNFに書き変わって格段に分かりやすくなった感じがする。また進めていきたい。以下エントリ、めっちゃ尊敬していて、9cc一通り終わったらRustでやりたい、が、本当に半年以上拘束されるだろうしよく考えねば、とは思っている。qiita.com9cc終わったら以下の感じでRustやってみてもいいかも！Rust書いたことないですが、バックエンドllvm使うなら比較的早く終わるかもしれないですね。https://t.co/1cdETux5rX10日でCコンパイラ書いたというこの記事みて衝撃をうけました。僕がもしやるとしたら、これをRustに移植して感覚を掴んでからRustコンパイラ書いてみて、見積もりすると思います— ドキュネオ (@DQNEO) 2019年5月24日OSの作り方を学ぶOS作ってみたいよねと思ったので30日でOSが作れるという本を90日くらいかけて終わらせた。以下、始めたエントリは書いたけど終わったエントリ書いてないね…dekotech.dekokun.infoそれまでOSが何をやっているのかよくわかってなかったが、本を読んで、いろいろなことを学べた。本格的にC言語を書いたのも初めてだったので学びが多い。この本によってかなりTuring Complete FMの内容が理解できるようになって嬉しかった。このエントリに対しての感想として以下エントリを教えてもらった。良さそう。次OSやる時はxv6見てみるぞ！何がOS実装の理解を難しくしているのかとGNU assemblyの準備 - QiitaRustでOSを書く(ペンディング中)上記30日OS本の内容をRustに移植しようといろいろやっていたが、残念ながら途中で頓挫した。何かうまくいかない際のデバッグの方法が難しかった。デバッグのために文字列出力させていたけどたまにうまくデバッグ文字列が表示されない、sereal port経由でoutputするか…となったけどそこもうまくいかず、一旦ペンディングしたのであった。github.comので、RustでOSを書いている文献を探し、以下Writing OS in Rustをみつけてやっていた。os.phil-opp.comWriting OS in Rustを読みつつ書いてるリポジトリはこちら。Writing OS in Rust、最近色々書き直されているようでそれに追随できておらずこちらも今ペンディング中。github.comRustを学ぶ低レイヤを触りやすい言語、及び以前Haskellを学んでいたこともあり型システムがしっかりしている言語を一つ学んでおきたいという気持ちがあって、そこにちょうどRustがあったので学び始めた。以下本を購入して読み通すことで、Rustの知識以外のいろいろなことも学ぶことができて大変良かった。具体的には、当時の私はHeapとStackがプログラムの中でどう使い分けられているのかとかそういう知識があまりなかった(上記あるように事前に30日OS本は読んでいるので、OSからみてどう使い分けているのか、というのは知っていたが)が、この本を読むことである程度知ることができた。https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0Rust-Jim-Blandy/dp/4873118557/ref=asc_df_4873118557/?tag=jpgo-22&linkCode=df0&hvadid=295706574430&hvpos=1o2&hvnetw=g&hvrand=14566952903449752437&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1028853&hvtargid=pla-526453140636&psc=1&th=1&psc=1www.amazon.co.jphttps://www.amazon.co.jp/dp/4839919844/ref=cm_sw_r_tw_dp_U_x.M52CbQZYPEB2https://www.amazon.co.jp/dp/4839919844/ref=cm_sw_r_tw_dp_U_x.M52CbQZYPEB2プログラミングコンテスト系のサービスをやってみるアルゴリズムやデータ構造周り楽しそうだなぁと思っていたのでそのあたり学ぶために以下をやっている。LeetCode何かやりたいなと思っていた時にちょうど以下エントリを読んで、"LeetCodeって面白そうじゃん" となったため1~2日で1問ペースで解いていっている。leetcodeは、回答をsubmitして失敗した際に失敗した問題が分かるのが勉強しやすくて好き。全部Rustで書いてる。kumagi.hatenablog.comAtcoderLeetCodeのコンテストが毎週日曜日にあるのだが、毎週日曜日は消防団の訓練で外出していることが多くあまり参加できていなかった。そんな時、会社の若者が"コンピュータ・サイエンス学びたい" という話をしていたので、"じゃ、一緒にAtcoderでコンテスト出てみよう" と誘った。今度その若者と一緒に初参加予定。楽しみ。計算理論の初歩を学ぶ初歩的なところから学んでいきたい。そもそもまだ計算理論ってのがなんなのかもよくわかってないんだけど。白と黒の扉を読むコンピュータ・サイエンスを文献で学びたい、という思いが強くあったがどの本がいいかわからず、検索していたらこの本を紹介しているエントリがあった。かつて購入して読んでいたこともあり、再度読んでみた。小説なので読みやすく、形式言語とオートマトンについて学べる。大学の教科書で使われているような書籍で学ぶid:hokkai7go さんに コンピュータ・サイエンス学びたいけどどうすればいいかねぇ という話をしたら大学の教科書をおすすめされたので、上記白と黒の扉に記載してあった参考文献の中の一番基本的に見えた、計算理論の基礎を買って読んでいる。最初に数学の基本的な事項を学び、その後有限オートマトンと正規言語、非決定性有限オートマトンと決定性有限オートマトンの等価性、などなどあたりまで読んだ。まだ半分くらい(というか全3巻のうち、1巻の半分くらい)なので先は長いが、とにかく面白い。現在、有限オートマトンと正規言語周りの話を勉強していて、スター演算ってのが出てきてふむふむとやっていたら正規表現の話になって、正規表現の “*” って言語の正規演算としてのスター演算子だったんだなぁという驚きが得られた。— でこくん (@dekokun) 2019年5月3日システムのパフォーマンスについて知る会社で詳解 システム・パフォーマンス輪読会がやっていたので途中から加わった。このエントリの中では一番仕事に役立ちやすい分野のような気がする。現代の(と言ってもそんなに新しくはないけど)Linux（Solaris）について詳しくなれる(まぁ、Solaris特有のところは結構読み飛ばしつつやってる)。今はその輪読会がそのまま、 パフォーマンス計測ツールを作ろう の会に変わって各人Cやらなんやらでツールを書いている。私はRustでstrace的なものを作ってみよう！ってのを最近始めた。まだ始めたばかりなのでほとんど何もできていない。github.com続けるための仕組み思想の骨子は以下エントリにかかれている通り。とにかく子供がいるとまとまった時間をとるのはかなり難しいため、1日ほんの少しでいいからターゲットを決めてコツコツ進めていく、ということを大切にやっている。nhiroki.jp"カンバン仕事術" っていう本に書いてあると id:Songmu さんに教えてもらった始めることを終わらせ終わらせることを始める という言葉がとにかく気に入っている。アウトプットしたいことが多すぎて時間が追いつかない。時間もまとまった時間は取りづらい、そんなお悩みをお持ちじゃありませんか？？？しかしそういう場合でも “始めることを終わらせ終わらせることを始める” を徹底すれば…！！！なんと、…！！！！！終わっていくのです！これはすごい！！！— でこくん (@dekokun) 2019年3月20日しかし、コツコツするにしても、人生の幸せにおいては子供と遊ぶのも睡眠も仕事も重要であり、子供と遊んだり子育てをしつつ仕事をしつつ睡眠を毎日9時間とか取りつつという生活をしていると、普通の意識でいるとコツコツやっていく時間すらほぼなくなる。が、まぁ以下ちょっとずつ時間をとれるような工夫をいくつかしてコツコツ頑張っている。やることを書き出し日々メンテするTodoistに日々やる細かいことと勉強したいことを繰り返し予定で全部入れ、それが全部達成できることを狙って日々過ごす。しかし、睡眠時間のほうがより重要なので、終わってなくても寝る。終わってない日々が続く場合はやることを減らすなど、無理のない範囲でできるようにメンテナンスする。不要なことをしない毎月、今月やらないことを決めてそれを徹底している。例えば、 今月は一切マンガを読まない 今月ははてブはテクノロジーカテゴリ以外読まない など。それを毎月積み上げていっている。以下TED動画で、今月やることやらないことを決めて徹底しろって言っていて、この動画を一時期ひたすらシャドウイングしていたこともあって頭に完全に刷り込まれた。www.ted.com最近は、 これやりたいな と思ったことは全部spreadsheetに順位付けして放り込んでいる。将来これを頭からやっていくぞ！ と思うことでだいぶやりたい心が抑えられる。本当にやりたいことは、分解して上記日々のTODOに突っ込んでいっている。最近の1日毎日こんな感じで生きてる。先週末に抜歯したら歯が痛くてここ数日自分の時間に集中できてない、という問題はあるのだけども…ここに、定期的に消防団の訓練などが差し込まれてくる。朝5~6時起床、子供と遊びつつ細々とした家事を行う。朝ごはんのセッティングも〜7:00 子供と散歩〜8:00 子供に朝ごはんを食べさせつつ自分の朝ごはんを食べ、食器の片付けなどなど〜8:40 おかあさんといっしょやいないいないばあを観せつつ妻が子供を見てくれつつ私は子供をみたりleetcodeの問題を読んだり子供を保育園に送りつつ会社へ。移動時間にPodcastを聞くランチ時間に高速で食事をし、このエントリで書いたような、やりたいことをやる20:00 家に戻ってくる(もうちょっと早くできるので早くしたい。終業後、15分位ダラダラしてしまう)~20:40 お風呂、食事、翌日の朝食の準備~21:30 このエントリで書いたような、やりたいことをやる就寝。疲れたと感じた日はちょっと早く寝る。ディープライフ日々めっちゃ細切れの時間しか取れないため、ディープライフを意識してやっている。この発表資料読んで、 私も子供と目一杯遊ぶぞ！ という気持ちになれました。matsumotoryさんには大変感謝しております。speakerdeck.com蛇足このエントリ、消防団の話がちょくちょく出てくる。 それを減らせばコンピュータサイエンス学べるのでは というのはあるのだが、消防団は以下、第三次世界大戦を生き延びるために入っているのでこれも優先度は結構高いのであった。消防団、体が鍛えられて結構便利。というか冷静に思い返すと、消防団は家族との触れ合い同様に数少ない私のストレス解消手段として機能している気がした。dekolife.hatenablog.com

コンピュータ・サイエンスやりたくなって1年ちょっとコツコツやってる/やったことたち

rust.connpass.comでの発表内容です。自己紹介id: dekokun (twitter, hatena)dekokun iconSREやってますCDNのDはdekokunのDって最近ずっと言ってます。これからCDN周りに力を入れていくぞという思い。詳しくは以下エントリに書いてます。dekotech.dekokun.infoFastlyのedge computing環境 Terrariumの紹介そもそもedge computingとはコンピューティングリソースを利用者の端末に近いネットワークの周縁部（エッジ）に配置することにより、低遅延応答、分散処理、トラフィック最適化などを実現するものと言える  (参照： https://www.icr.co.jp/newsletter/wtr348-20180329-sadaka.html )この発表では、特にCDNの各edge上でユーザの書いたプログラムが動く環境を指して "edge computing" と言っていますTerrariumについてwww.fastly.comWebAssemblyベースのedge computingプラットフォーム(まだ実験的なサービスRust/TypeScript/Cからwasmファイルを生成し、Terrariumの中で動いているLucetがwasmファイルをネイティブコードに変換し、実行しているLucetはコンパイラかつ実行環境。高速に起動することが特徴。最近発表されて WebAssemblyが50マイクロ秒以下で起動する「Lucet」。コンパイラとランタイムをFastlyがオープンソースで公開 というエントリが最近バズってましたねログインなしで触れる、最初から様々なアプリケーション例があり簡単にデプロイできるTerrarium - Fastly Labs にアクセスすると、いろいろなサンプルが出てきて簡単にデプロイできるDNS Over HTTPS by Rustお天気アプリ by RustGraphQL by Rustポチポチでデプロイ完了デモTerrarium - Fastly Labsコマンドラインツールでデプロイも可能以下の私の作ったデモ画像を見ると、デプロイがCLIだけでできるのが分かる。github.comKVSも使えるlowreal.net5分で中身が消え去る。キャッシュ的用途に使うことを想定されていると思う。中の作りTerrariumのruntimeはいくつかの関数を定義しており、Rustから使えるようにCのFFIを使用してそれらを宣言する必要がある(このあたりで行っている： https://wasm.fastlylabs.com/docs/rust/http_guest/hostcalls/raw/index.html )それをこのまま使うとunsafeなので、fastlyの提供しているhttp_guest crate内にwrapperがありユーザは主にそれ経由でTerrariumとやり取りすることになる。wasm.fastlylabs.comまた、私の書いたコードを見ると分かるように、 guest_app_kvs! というマクロが、Terrariumのruntimeとユーザの書いたコードとの橋渡しを行ってくれている。マクロ内部では、runという名前の関数が定義され、主にpanic handlerとメモリ管理関数の設定をしている。https://github.com/dekokun/terrarium_demo/blob/240e5c198a2de1547e9f963cc6b24b7339eacbc6/src/lib.rs#L28// 前略pub fn user_entrypoint(kvs: &mut KVStore, req: &Request<Vec<u8>>) -> Response<Vec<u8>> {// 中略  Response::builder()    .status(200)    .header("Content-Type", "text/html")    .body(body.as_bytes().to_owned())    .unwrap()}guest_app_kvs!(user_entrypoint); # これ今後も目が離せないedge computing今回、Rust LTということでRustと親和性の高いTerrariumの話をしましたが、他にもedge computing環境はどんどんでてきており、目が離せません。Terrarimu自体もまだサービスで使えるわけではないので、サービスで使う時はどんな感じになるかも大変楽しみです！ありがとうございましたenjoy !

Fastlyのedge computing環境、Terrarium(Rust LT #4登壇

私とCDNとedge computing最近、CDN各種に続々とedge computing周りの機能が入っており1、現在においてCDNでどこまで何ができるのかみたいなことをよく考えており、仕事でもやっていきたいな、と考えている。以下発表で フルCDNアーキテクチャ の提言をしてから3年が経ち、今ではフルCDNはかなり当たり前の選択肢としてそこにある、というかマイクロサービス間の通信もCDNを通すようなことまで行われる世界になっており純粋にすごいなと感じている(そもそも フルCDNとはなにか というのは私の中でも確たるものがあるわけではないが、イメージ的には動的なサービスにおいてもすべてのエンドポイントをCDN経由で返し、ある程度柔軟なキャッシュのPurgeを行うようなものを想像している2  3)。speakerdeck.com上記、私は提言するだけしたが、その後そこに強く取り組もうとしてこなかったのに若干の後悔がある(動的な部分もTTL0で全部CDNを通す、のようなことはやったりはしていたが)。CDNに限らない、様々な意味でのedge computingという文脈では、以下さくらインターネット研究所のビジョンを見ても、これはすべてがユーザの近くとしてのedgeとして動きながら、それぞれが必要に応じて協調していくという話であり、夢広がるなぁなどと思いつつ見ている。research.sakura.ad.jpまた、話は変わるが私はJSを前職でゲームを作るなど書きまくっていたりした。CDNのedge computingとフロントエンドは親和性が高いと思っており、そういう意味でも私はここに取り組むべき人材なのではないかと感じている。CDNでのedge computingはどこまでfrontendの話題と言えるのかはわからないが、edgeで計算させることによるレイテンシ短縮やBFFとしてのedge computing等、フロントエンドの必要とする世界のためのグルーとしてCDNのedge computingを捉えることもできると思っている。そもそもどこまでがフロントエンドにまかせてどこまでをedgeに任せるか、どこまでをオリジンに任せるかというところから様々な組み合わせが考えられ、まさに大変夢の広がる話である。エッジコンピューティングを活かしたウェブアプリケーションホスティング構想 - ゆううきブログ や 超個体的DBクエリキャッシング構想 - Speaker Deck などを見ても、 edgeにそこまでやらせるか〜 と大変おもしろく、更に夢が広がっていく日々である。というわけで、CDNのedge computingをやっていくぞとなったはいいが、では実際に何をやっていくのか、と思っていたらうちのチームのテックリードが"これdekokun好きそう"と言って以下URLをくれた。訳してみたところなかなかおもしろく、扱っているものがWebAssemblyということもありちょうど最近私はRust + WebAssemblyのアプリ作ってたしまずはfastly + edge computingを見ていこう、となったのであった。www.fastly.com上記URLの内容は、かなり雑に要約すると以下となるfastlyはlab立ち上げていろいろやってるよ、Terrarium,っていうプロジェクトが熱いよ。これはWASMベースのエッジコンピューティングプラットフォームだよ。早くて安全だよTettariumはsystem callの実装が多くなく、std libのほとんどが使えない。副作用の起こし方はhttp_guestというライブラリを使ってやってねKVSも使えたりするよその後、http_guestの具体的な使い方の説明が続くなお、Terrariumはログインなどなしで誰でも気軽にwasmアプリ(という表現が適切だろうか、wasmで動くサーバサイドアプリ？)をデプロイできるから皆試してみるといいよ。wasm.fastlylabs.comなどというわけで、Fastlyには今非常に注目しているわけです。で、 Fastly Yamagoya Meetup 2018 に参加して最高と思ったり、最近はFastly Meetup #2に参加したりしました。以下、fastly meetup当日メモ。上記Terrariumの中で動いているLucetについての話もあって嬉しかった。fastly meetup当日メモIntro営業のToshi Aizawaさん による、fastlyの紹介とデモFastlyのメリット以下、デモをしながらリアルタイム性を見せてくれたんだけど、キャッシュのpurgeが本当にすぐだったし、logもアクセスしたら数秒でpapertrail上に流れてきたし、設定変更の内容が反映されるも、35秒くらい(いつもは10秒とかもっと早いとのこと)、というのを分かりやすくデモしてもらえていて大変うまいデモだった。設定変更は、35秒だとしても、かなり早いという印象(私の触ったことのあるCDNと比べて)メモリアルタイムinstant purgelog streamingconfig changecloud native(easy to manage)api first, api everythingので、CI/CDに組み込みやすいパフォーマンスがいいキャッシュヒット率が高いHow we build Fastly with FastlyTatsuhiko Miyagawaさんによる、Fastlyで動いているFastlyのコントロールシステムの裏側についての話。Fastly Yamagoya Meetup 2018で話されていた内容とほぼ同じ内容(と本人も最初に言っていた。fastlyの裏側でfastlyが動いているというのが面白い。fastlyが全体的に障害に陥った時に裏側も一緒に死ぬので大丈夫なのだろうか、というのは気になった(質問すればよかった)。VCLのテストは同じ設定をもう一つ作るのがベストプラクティス、というのはAPIで操作しやすいからこその選択肢だなと感じた。メモfastlyのAPIはfastly上で実装されているVCLでroutingしている最近、APIのbackendを切り替えた古い方から徐々に新しい方に流して最後にshutdownするAPIのroutingサービスもfastlyに全部のせた。chefでデプロイしていたのがterraformでデプロイされている確率的にAPIを古いbackendに流したり新しいbackendに流したりした新しい方にヘルスチェックを入れておいて、ヘルスチェックを落とすことで戻す、みたいなことも可能A/Bテストで、例えばヘッダにユーザIDとか入れて、それをsha256で振り分けるとかできるfastlyの行っているcanary deploy方式火曜日と木曜日にデプロイしているまずcanary サーバにデプロイ。リクエストにcanaryのヘッダが入っていたらcanaryバックエンドに飛ぶように普段はproduction clusterを見ている。canary リリースの際はcanary クラスタにリクエストが飛ぶようになる。HTTPヘッダでcanaryに飛ばすなどがfastlyで可能。その場合、varyでそのヘッダを定義してあげる必要がある。これによってキャッシュが分離されてcanaryが変な動きしてもproduction側には影響を及ぼさないconfigを各edgeに対してどのように配信しているかpull型。edgeがcontroll planeにpollしている。何かが変わったタイミングでキャッシュがpurgeされて新しいものを取得できるというモデルfastlyのキャッシュサーバはリクエストをthundering herdを防ぐ機能としてクラスタリングしているため、pull型でも TTLが切れた/キャッシュpurgeした瞬間にoriginに大量アクセス のようなことは起きないクラスタリングは何も設定していなくても勝手に有効になっている。(ここ、若干本当にこれで正しかったか確認したい。特にshieldに関する理解が曖昧) objectのハッシュ値を調べてmasterを調べてそこに投げる。その後もう一段階同様のことをして、originに投げる。originへのリクエストはshieldからしか来ない、ということもできるshieldについて参照： オリジンシールド - パフォーマンス・チューニング | Fastly Help Guidesoptimizing deliveryVCLのbinaryへの変換を全てのedgeでやっていたがもったいないので、binaryを作って配信するようにしているrouting service(fastlyのedge cloud自体のことを指している)がcompiler serviceに問い合わせ、compiler serviceがroutingにVCLを問い合わせ、control planeからVCLが返され、compilerがbinaryに変換してedgeに返すnode, pop, customer毎に少しずつbinary直接取得へ変更していったedgeが、"おれはbinaryを受け取れるぜ"というのをaccept headerで表現。accept headerで渡してもテキストが返る場合もある(control planeがその判断をする)。routing serviceはcontrol planeにbinaryを返すか確認し、カスタマーやサービスのfeature flagをみてyesだったら、binaryを返すようにするaccept: varnish-soであり、かつ、compiler_service.healthyであればcompilerに行く。つまり、compilerのヘルスチェックを落としたら全部戻る(質問) vcl反映する時に行われること、vclのテストの仕方についてsyntax checkでapiからエラーが返るvcl自体をローカルでテストするのは一筋縄でいかないので、同じ設定を持つ別のサービスを作ってそこにリクエストを送ってテストするのがベストプラクティスvclFiddleというサービスでチェックすることもできるfastlyではapiのデプロイはterraformを使っていて、そこにPRを送ってマージされるとデプロイされるIntroduction to Lucetここが今回一番聞きたかったところであったが、もう体調不良と英語と内容の難しさによりほとんど頭が理解できなかった…英語の部分は同時通訳さんいたんだけど、同時通訳ありの発表に慣れていなかった、というのもある。メモCTOより少人数のリサーチチームを率いているterrariumはlucetで動いているlucetの内部構造についてlucetはcompilerlucetはruntimeでもある。安全と分離lucetはツールセットでもあるプロファイラ・デバッガとの統合も考えているwasmには、静的型付けの個人的上位のTS, Rust, Cの3つが合理的、好きwasmへのコンパイルはlucetの外で行われる。assemblyscript, rustc(Rust), llvm(C)wasiというスタンダードをmozillaと作っているwasmの外界へのinterfaceがそれぞれのcompilerで別の取り組みをしている。wasiがなんらかのインターフェースを与える、posixなどと似ているwasmでedge computingを考えているlucetはブラウザの外でwasmを動かす場合の答えwasm -> lucet -> native codeAOT compilerによってelfオブジェクトファイルとなるlucetc はlucetのcompilerサイドwasmのparser -> verifier(compileしようとしているものが有効なモジュールなのか、有効じゃないと危険) -> translator(wasmのbyteコードを中間表現に) -> codegen -> artifact(metaデータに沿ってパッケージ化) -> runtime上記のcodegenはcranelift(コレ自体がverifierのような動き)が行う。craneliftはmozillaと共同開発verifier(中有感表現が正しいか) -> preopt(最適化) -> legalizer(native code生成の起きているところ。特定のプロセッサでコード認証(legalize)が行われる。machine codeと1対1のマッピング) -> postopt(特定のアーキテクチャをターゲットとして最適化。いくつかのload/storeを統合してsingle instructionにする、とかがよく行われる) -> register allocator(すべてのシンボリック変数を取り込む) -> branch relaxer(説明は割愛。メモリの最終コードをどのようにレイアウトするか)runtimemetadata, globals, linear memory, guest stack, signal stack のようなメモリの細部のレイアウト。数千、数万の並列処理ができるようになぜこれをわざわざするか？お客に最新のedge computingを提供したかったが、パフォーマンスと安全性に多大なる配慮をしていて、提供したい機能を提供できてなかった。安全性とパフォーマンスを両方できるテクノロジーがなく2年前に作り始めた、lucetとしてopen sourceで作り始めたOSXのサポート。x86-64のみで現在は実行。fastlyはintellのプロセッサのみ。lucetのlive demolucetとwasiがどんなふうに動くか(注：以下、dekokunは全然理解せず機械的に前に写ったものを書き写したのみであるfastly/lucet: Lucet, the Sandboxing WebAssembly Compiler.helllo.cをまずwasmにcompule。 wasm32-unknown-wasi-clang hello.c -o hello.wasmwasm-objdump -h hello.wasmwasm-objdump -xj function hello.wasmlucetc-wasi hello.wasm -o hello.solucet-objdump -t hello.so | grep "F .text" # ノーマルなelfファイルにlucet-wasi hello.so質問cranliftとlucetの違い。cranliftはlaw levelで安全性の保証ができていないコンテナで走らせるのと何が違うのかv8やコンテナと比べて軽量、大量のインスタンスを高速に起動できるLT残念ながら体調悪くて早退…聞きたかったネ…以下、流れていた発表資料に対する感想。blog.spacemarket.com私もCookieを見てキャッシュを出すかどうかの実装をしたことがある。非ログイン状態のキャッシュ、テレビや突然の検索流入対策などに圧倒的に便利。それが自前でコンポーネントを用意しなくてもVCL書いてCDNで動くのはやっぱ圧倒的に嬉しいよなぁ。speakerdeck.com404がキャッシュされて大変ってのは、あるある…対策部分にも書いてある2つがまさに重要な対策だなぁ。誰でもいつでも簡単にハマる罠だと思うので今後私も気をつけよう…最後に上記2本の内容は別記事にしても良かったが、fastly meetup中にどんどん体調が悪くなりあまり内容が理解できず、最後は途中離脱したので書くことがあまりないというのもありコンテンツ2本立てにした。関連のある内容だしまぁいいだろう。更に最後にCDNのDはdekokunのDです(と最近社内で言い続けている。id:papix さんが考えてくれた最高の標語。ありがとうございます。まだ実績は伴っていないので実績作っていきたい例えば、 エッジコンピューティングに向けた分散キャッシュ技術の調査 - ゆううきブログ にはAWS Lambda@Edge2，Cloudflare Workers3，fly.io4の例が出ているし、本エントリで扱うfastlyのTerrariumもその一つである↩光を超えるためのフロントエンドアーキテクチャ - Speaker Deck のCache Awareな設計参照↩もっといい名前募集中。ってかこれを書いていて上の脚注の Cache Awareな設計 でいいんじゃね？という気もした。CDNにこだわる必要もなさそうな感はある。↩

私とCDN、及びfastly meetup #2

Real World HTTP ミニ版を読んでいてSPDY, HTTP/2, HTTP/3におけるHTTPヘッダ圧縮について触れられていた。このエントリではそこを深掘りし、SPDYのDeflateに始まるHTTPのヘッダ圧縮がどのようにHTTP/3のQPACKにつながっているかを書く。(これで正しいのか誰か教えてほしいSPDY時代： DeflateSPDYのDeflateは部分文字列一致で圧縮した後にハフマン符号化によって圧縮する。部分文字列一致による圧縮であるため、一部でも文字列が合致した組があると圧縮されるということから、リクエストを1バイトずつ内容を変えて送信し、フレームの長さを見ることで内容を推測するようなCRIME攻撃に弱かったため、圧縮機能は非推奨となった(という認識だけど正しい？HTTP/2時代： HPACKHPACKはヘッダ名もしくはヘッダの値に対する完全一致でハフマン符号化による圧縮を行うためCRIME攻撃への弱さは克服している。事前に定義された静的な辞書と動的な辞書を使っており、動的な辞書は送信側が投げる順番で受信側がヘッダを受け取ることを想定した作りとなっている。TCPの条件下ではこれは守られるが、HTTP/3のようにTCPを使わずストリーム内においてのフレームの順序さえ守られてさえいればいいという制約化(=別ストリームのフレーム同士は送信順に関係なく受信されうる)においては、動的な辞書の内容が送信側と受信側で一致するという確証が持てないため使えない。もしなんらかの方法でそれを直列化するような実装にした場合、せっかくストリーム単位での順序制御にしてHead of Line Blockingを減らそうとしているのにHPACKのためにBlockingが発生してしまうことになる。HTTP/3時代： QPACK上記HPACKをHTTP/3上で使う場合に発生する問題を解決するために、辞書の追加時はキーと値の情報をやり取りし、削除はお互いが同意をとって実施することで若干圧縮率を犠牲にしつつ、順序に依存しないQPACKとなった。これにより、順序を守る必要はなくなったためストリーム単位でのフレームの順序制御にも大きなブロッキングが起きず使えるようになった。ただし、別フレームで追加されたキーが参照された際は、ブロッキングが起きる。これを防ぐため、別ストリームでそれぞれ同じキーの追加を行ってもいいとかなんとか(詳しくない終わりにというわけで、関連知識を深掘りしそれを本エントリにまとめたのはいいんだけど、まとめ直した後に再度Real Workd HTTPミニ版の該当箇所を読んだところ、かなりの割合でこのエントリがReal Workd HTTPミニ版に載っていることの劣化版焼き直しになってしまっていることに気付いてしまった…。改めて、書籍ってすごいなと思ったが、私の学びの記録として本エントリはおいておく。皆は、このエントリ読まずにReal Workd HTTP読めばいいと思う。まぁ、このエントリを読むと、パッと見で時系列がある程度分かる、という利点はある。2019/04/08 18:05 追記よくみたらこのエントリのpublishの少し前に以下のような、このエントリの上位互換のようなエントリが出ていた。皆はこちらをみたほうが幸せかもしれない。HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog本エントリにあたって参考にした文献Real World HTTP ミニ版DeflateについてDeflate - WikipediaDeflateCRIMEについてSSL/SPDYを攻撃するCRIMEはBEASTの正統な後継者だ - WAF Tech Blog ｜ クラウド型 WAFサービス Scutum 【スキュータム】HPACKについてRFC 7541 - HPACK: Header Compression for HTTP/2事前に定義された静的テーブル RFC 7541 - HPACK: Header Compression for HTTP/2QPACKについてQUICのヘッダ圧縮QPACKとは (旧QPACK) - ASnoKaze blogQUICにおけるヘッダ圧縮の提案仕様 QPACK(旧QCRAM) - ASnoKaze blogQUICにおけるヘッダ圧縮の提案仕様 QPACK(旧QCRAM) その2 (draft-04) - ASnoKaze blog

HTTP/3のQPACKに至るHTTPのヘッダ圧縮の流れメモ(Real World HTTPを読んで

Mackerel Advent Calendar 2018 - Qiita 8日目です。私は気分の上下が激しく波のようだということで、チームメンバーから"デコウェーブ"などと言われていたりするのですが自分ではいまいち認識できてないな、ということで可視化を進めることにしました。可視化の方法としていろいろあるかと思いますが、今回はMackerelを選択しました。Mackerelのいいところとして、日記がかける事が挙げられます。私の健康状態のグラフこんな感じでグラフができて…ちょっと山ができているこの日はちょっと調子良さそうだけど何が起きたのでしょうか？？？筋肉は偉大なるほど、筋肉のおかげか、ということがわかりますね。Mackerelのグラフアノテーション機能を使って上記のように日記を書いています。これを投稿しているのは以下スクリプトです。 $ dekokun_health.sh 3 筋肉を追い込んだ みたいに使いましょう。レッツトライ！$ cat dekokun_health.sh#!/bin/bashif [[ $1 == "watch" ]]; then    open "https://mackerel.io/orgs/XXXXXXXXX/services/XXXXXXXX?metrics=service"    exitfiif [[ $# -ne 2 ]]; then  echo "Usage: $0 点数 説明"  >&2  echo "点数は4点満点。  0: 最悪な気分  1: 気分悪目  2: 気分普通  3: いい感じ  4: 最高！"  >&2  exit 1fimetric=$1description=$2service=dekokunprintf "health\\t%d\\t%d" "$metric" "$(date -u +%s)"| mkr throw --service $servicemkr annotations create --service "$service" --from "$(date -u +%s)" --to "$(( $(date -u +%s) + 1))"  --title "$description"mkrコマンドのセットアップ方法やAPI KEYの使い方は以下を参考にしてくださいmackerel.io次にやりたいこと今はPCの前じゃないと値を投稿できないのが辛い。ブラウザから投稿できるようにすればいつでも投稿できてハッピー☆上記以外にももっとたくさんデータを投稿する工夫をなんらか施しデータが溜まってきたらなんかいい感じに分析したいね。 夕方はウェーブが激しいね 、とか

Mackerelに日記を書きながら健康状態をトラッキングする

結論特に設定しないとproxy_passで設定するupstreamのmax_failsは1proxy_next_upstreamに指定したstatus codeが出ると失敗扱いになってmax_failsに達すると一時的にそのupstreamは使えなくなる検証ポート30000, 30001で、常にHTTPステータス503を返すエンドポイントを適当にMac上で動かしてこんなnginx.confを作って$ cat /tmp/nginx.confuser  nginx;worker_processes  1;error_log  /var/log/nginx/error_log info;pid        /var/run/nginx.pid;events {    worker_connections  1024;}http {    include       /etc/nginx/mime.types;    default_type  application/octet-stream;    log_format ltsv "time:$time_local"                "\tstatus:$status"                "\treqtime:$request_time"                "\tupstream:$upstream_addr"                "\tupstream_status:$upstream_status"                "\tvhost:$host";    access_log  /var/log/nginx/access_log  ltsv;    sendfile        on;    #tcp_nopush     on;    keepalive_timeout  65;    #gzip  on;    upstream myapp1 {        server docker.for.mac.host.internal:30000;        server docker.for.mac.host.internal:30001;    }    server {        listen       80;        server_name  localhost;        location / {            # ここが重要            proxy_next_upstream error timeout http_502 http_503;            proxy_pass   http://myapp1;        }    }}こんなコマンド打ってnginxを起動して$ docker run --name my-custom-nginx-container -v /tmp/nginx.conf:/etc/nginx/nginx.conf:ro -p 80:80 -d nginx$ curl localhostこうするとこんなログが出て2018/12/04 12:32:31 [warn] 6#6: *12 upstream server temporarily disabled while reading response header from upstream, client: 172.17.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "http://192.168.65.2:30000/", host: "localhost"もう一度curlするとこんなログが出て502が返る2018/12/04 12:33:03 [error] 6#6: *18 no live upstreams while connecting to upstream, client: 172.17.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "http://myapp1/", host: "localhost"ドキュメントModule ngx_http_upstream_module の max_fails あたり。By default, the number of unsuccessful attempts is set to 1.What is considered an unsuccessful attempt is defined by the proxy_next_upstream,なるほどねぇ。next stepdocker composeでやったほうが再現が楽だしブログも書きやすいしいいことづくめ。次やる時はdocker compose使う

nginxのpassive checkの挙動確認

低レイヤを知りたい人のための Cコンパイラ作成入門、こちら、日々更新されている書籍(?)なのですが、現在書かれている部分まで完了した。コードは以下。Docker上で開発していて、Travis CIでのテストもしている。github.comよくわからなかったところ全部のコードが載っているわけではないので、 "動くには動いているが本当にこれでいいんだろうか？" という部分がいくつかあった。mulやexpr内で自分の読めない文字の判定以下のように、mulの最初でひたすらmulの扱わない文字を弾いていっているのだけど、(更に言うとexprの最初でも同様のことをやっているんだけど)、もっとエレガントな方法はないのだろうか、このままでは記号は増えるごとにこの条件が増えていくぞ…？と考えている。https://github.com/dekokun/9cc/blob/955ec5aa6c44e1c9cd1721ace7e8140cd357419a/parse.c#L79しかし、mulが呼び出されたらmulは自分の読める範囲内で最大のところまで読まないといけないし、そうすると自分の読めない文字も知っていないといけないよなぁ、だからこれでいいんだろうなぁ、と思ったりもしている。(追記)と、このエントリを書いてちょっと考えていたら以下のように修正すればいいんじゃね？と思って修正した。パッと考えて実装してテストも通ったからコミットしたけどエラーに弱くなったりするのかな。ちょっと考えないとわからないし今日はもう寝る。読めるところまで読んで読めなかったら返す · dekokun/9cc@ec14865 · GitHub(更に追記)布団の中で考えていたが、やっぱ例えば 1 1 みたいな入力を与えられた時に、これまではmulで止められていたのがassignまで上ってきてエラーの分類能力が弱くなっているな…ダメか〜。まぁ寝る。util_testでのgccからの警告コンパイル時にhttps://github.com/dekokun/9cc/blob/40fe86304cf08139611615971303fb57284e01f1/util_test.c#L28 のあたりで util_test.c:28:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] という感じで、integerと void * のサイズが違うよって言われていて、64bit環境だと違うよね、とは思うんですがこのエラーを解消させるうまい方法はあるのだろうか… void * をやめるとかしかない…？？と思った。感想以下でもruiさんを参考にプログラミング言語を作って楽しかったので今回も楽しいだろうなと思いつつ始めたらめちゃくちゃ楽しくてドハマリしている。dekotech.dekokun.info再帰は難しいなと改めて思うし、再帰から再帰を繰り返して魔法のようにプログラムが解読されていくのは本当にワケワカラン感じですごいなと思う。とにかくturingcompletefmを聞きつつこれをやりつつ、ruiさんみたいな感じになりたいな("みたいに" とは何か)と最近思う日々なのであった。

"低レイヤを知りたい人のための Cコンパイラ作成入門" 、現在書かれている部分まで完了してよくわからなかったところ

世間ではLambdaをデプロイするのにapexを使うのがいいかcloudformationを使ってデプロイするのがいいか、みたいな話があると思いますので、cloudformationでのデプロイ方法をここに書くことでその判断の一助になれば、及び、世間ではcloudformation packageコマンドの認知度が低い感じがするのでそれについてももっと知らしめたいという感じでこのエントリ書いてます。公式ドキュメントpackage — AWS CLI 1.15.10 Command Reference簡単な例での解説ファイルの準備以下のディレクトリ構造だったとします├── template.yml // cloudformationのyamlファイル├── build    └── lambda-go // `$ GOARCH=amd64 GOOS=linux go build` とかでビルドされてできたバイナリtemplate.ymlの単純な例(これは簡単のためAWS SAMを使っていますが、aws cloudformationコマンドでもだいたい考え方は一緒で、ただ以下 CodeUri の代わりに Code を使う感じになります)AWSTemplateFormatVersion: 2010-09-09Transform: AWS::Serverless-2016-10-31Resources:  xxxxxxxxxx: # 好きな名前をどうぞ    Type: AWS::Serverless::Function    Properties:      Handler: lambda-go # 上記バイナリのファイル名      Runtime: go1.x      CodeUri: build # 上記lambda-goが存在するディレクトリ名また、別途、成果物をuploadするためのS3バケットを作っておく必要があります。デプロイまず、以下コマンドによってファイルをS3にuploadし、上記CodeUri部分をS3のURLに書き換えたcloudformationのtemplateファイル(output.yml)を生成します。$ aws cloudformation package \        --template-file template.yml \        --s3-bucket $(上記成果物をuploadするためのS3バケット) \        --s3-prefix $(S3バケット内でプレフィックスをつけたかったらこれを指定) \        --output-template-file output.ymlそして、以下コマンドによって、上記コマンドで生成された output.yml を使用してLambdaがデプロイされます$ aws cloudformation deploy \        --template-file output.yml \        --stack-name $(CloudFormationのスタック名(任意)) \        --capabilities CAPABILITY_IAMめでたしめでたし。上記の仕組みが使われているMakeflieとCloudFormationのyamlファイルの紹介動いている様子は以下リポジトリの template.yml 及び Makefile で見ることができます。さっきもデプロイ成功しました。Makefileの中身を見ても aws-sam-localコマンドはあるけどaws cloudformationが出てこないじゃないか 、という話はありますが、これは aws cloudformation コマンドの代わりに aws-sam-local コマンドを使用している、という理解で大丈夫ですので、入れ替えてもらって大丈夫です。github.comGo以外のデプロイ基本的には上記と同じでPythonやNodeも、Zipファイルさえ作ってしまえば後は上記Goと同様にできるはずです(Nodeはやったことないけど)

dekokun

Kubernetes Jobでサイドカーを動かす際の問題と解決策

15時間くらい勉強して簿記3級に合格した

ゴールを探索しつつゴールに対するリスクを減らしながらゴールを達成していくのかが人生ですねぇ

Amazon Aurora MySQL のマイナーバージョンアップ、ブルー/グリーンデプロイメントを使う？ゼロダウンタイムパッチ適用を狙う？

GuardDutyの検知結果をslack投稿するアーキテクチャを考えた(あるいはAWSでイベントのフィルタを行うときに考えたこと)

みんなで会議をよくしていこう！と思ってやってるTips

求む、docker build に失敗した場合のデバッグ手法のかっちょいい方法

Kubernetes Meetup Tokyo #48 LT 登壇の一人反省会

個人運用k8sクラスタの構成要素の技術選定

bitcoinのfull nodeをAWSでなるべく安く運用してみる

Google Cloud の Associate Cloud Engineer 資格を取得するためにした勉強

JSONが格納された環境変数から、JSONのキーの名前とその値で環境変数をセットするツールを作った

ISUCON に Rust で参加して予選敗退

ISUCONに向けてRustでのリハーサルを実施した。採用したRustのライブラリなど

Next.js のチュートリアルやった

ICFPC2020に参加して73位だった

Google Code Jam Round1C参加して落ちた

子育てしながら人生を賭けてちょっとずつやっていく、私の勉強法

Kinesis Data Streams + Lambdaが詰まった時の対処法(RecoChoku Tech Night 5社合同 AWS re:Invent 2019 参加報告会登壇資料)

英語思ったより聞き取れなかった(AWS re:Invent帰り

いきち、しきいち

Rustの標準ライブラリにある構造体(BinaryHeap)を自前実装してみた

コンピュータ・サイエンスやりたくなって1年ちょっとコツコツやってる/やったことたち

Fastlyのedge computing環境、Terrarium(Rust LT #4登壇

私とCDN、及びfastly meetup #2

HTTP/3のQPACKに至るHTTPのヘッダ圧縮の流れメモ(Real World HTTPを読んで

Mackerelに日記を書きながら健康状態をトラッキングする

nginxのpassive checkの挙動確認

"低レイヤを知りたい人のための Cコンパイラ作成入門" 、現在書かれている部分まで完了してよくわからなかったところ

aws cloudformation packageを使ってGoで書かれたAWS Lambdaをデプロイする例

Kubernetes Jobでサイドカーを動かす際の問題と解決策

15時間くらい勉強して簿記3級に合格した

ゴールを探索しつつゴールに対するリスクを減らしながらゴールを達成していくのかが人生ですねぇ

Amazon Aurora MySQL のマイナーバージョンアップ、ブルー/グリーンデプロイメントを使う？ゼロダウンタイムパッチ適用を狙う？

GuardDutyの検知結果をslack投稿するアーキテクチャを考えた(あるいはAWSでイベントのフィルタを行うときに考えたこと)

みんなで会議をよくしていこう！と思ってやってるTips

求む、docker build に失敗した場合のデバッグ手法のかっちょいい方法

Kubernetes Meetup Tokyo #48 LT 登壇の一人反省会

個人運用k8sクラスタの構成要素の技術選定

bitcoinのfull nodeをAWSでなるべく安く運用してみる

Google Cloud の Associate Cloud Engineer 資格を取得するためにした勉強

JSONが格納された環境変数から、JSONのキーの名前とその値で環境変数をセットするツールを作った

ISUCON に Rust で参加して予選敗退

ISUCONに向けてRustでのリハーサルを実施した。採用したRustのライブラリなど

Next.js のチュートリアルやった

ICFPC2020に参加して73位だった

Google Code Jam Round1C参加して落ちた

子育てしながら人生を賭けてちょっとずつやっていく、私の勉強法

Kinesis Data Streams + Lambdaが詰まった時の対処法(RecoChoku Tech Night 5社合同 AWS re:Invent 2019 参加報告会 登壇資料)

英語思ったより聞き取れなかった(AWS re:Invent帰り

いきち、しきいち

Rustの標準ライブラリにある構造体(BinaryHeap)を自前実装してみた

コンピュータ・サイエンスやりたくなって1年ちょっとコツコツやってる/やったことたち

Fastlyのedge computing環境、Terrarium(Rust LT #4登壇

私とCDN、及びfastly meetup #2

HTTP/3のQPACKに至るHTTPのヘッダ圧縮の流れメモ(Real World HTTPを読んで

Mackerelに日記を書きながら健康状態をトラッキングする

nginxのpassive checkの挙動確認

"低レイヤを知りたい人のための Cコンパイラ作成入門" 、現在書かれている部分まで完了してよくわからなかったところ

aws cloudformation packageを使ってGoで書かれたAWS Lambdaをデプロイする例

Kinesis Data Streams + Lambdaが詰まった時の対処法(RecoChoku Tech Night 5社合同 AWS re:Invent 2019 参加報告会登壇資料)