はてなブックマーク

メリークリスマス！(フライング) AWS Containers Advent Calendar 2021 6日目の記事です。 先日、github.com/fujiwara/tracer という結構便利なやつを作りました。Amazon ECS タスクに関連するイベントとログを一括で出してくれる、シンプルな CLI です。 github.com 解説記事はこちら(会社のアドベントカレンダー)に書きましたのであわせてご覧下さい。 techblog.kayac.com tracer は単体の CLI で動作するのでどのような手段で管理している ECS タスクにも使えるのですが、これを ecspresso からも呼び出せると便利では? と思い立ったのでそうしました、というのがこの記事です。 ecspresso tasks --trace tracer は ECS クラスタ名とタスクIDを指定して動作

勝った！！引退！！！ 取り乱しました。 ずっと参加してきているWebアプリケーションパフォーマンスチューニングコンテスト ISUCON、ISUCON11本選にチーム「fujiwara組」で参加して、優勝しました。 ISUCON11 まとめ : ISUCON公式Blog fujiwara組は初回のISUCONから参加している老舗チームで、自分(fujiwara)以外のメンバーは都度入れ替わっているのですが、今回はISUCON10の時と同様に会社(面白法人カヤック)の同僚である acidlemon と macopy とのチームです。 チーム紹介スライド 過去に ISUCON1, 2, 5 で優勝しているので、6年ぶり4度目の優勝になりました。もう引退していいよね！(というか941さんに出禁って言われた気がする…) やったこと リポジトリはこちらです。 github.com アプリケーションの変

今年もやってきました ISUCON の季節です。 ISUCON は 8 までは(出題を含めて)予選本選の全てに参加できていたのですが、9, 10 では連続で予選落ちしていました。10は予選であと1チーム上回れば、というところで及ばずでしたが、本選には並行参加チームというオープン参加扱いで参加させてもらい、ひっそり全体の3位相当のスコアを出していたんですよね。なのでチームのポテンシャルとしてはまだまだいけるはず！ということで ISUCON 11 にも10と同様、同僚の @acidlemon と @mackee_w (macopy) と参戦しました。 結果、全体の4位のスコアで予選を通過できました！ isucon.net やったこととか 使用したのは Go 実装です。ミドルウェアは特に変更せず、最後まで nginx + MariaDB のままでした。 3台のうち1台を MySQL(MariaD

Amazon ECS のデプロイツール、ecspresso の v1.5.0 をリリースしたのでお知らせです。 github.com 今回は Amazon ECS Exec という新機能対応が目玉です。ほかにもお送りいただいたPRを取りこんだ各種修正が入ったリリースになります。どうぞご利用ください。 PRをお送りいただいた皆様、ありがとうございました！ 新機能 ECS Exec への対応を追加しました ホストから docker exec するように、Fargate に対しても起動しているコンテナに入ってコマンドを実行できる ECS Exec 機能がリリースされています。 aws.amazon.com ecspresso v1.5 では exec コマンドを追加して、AWS CLI なしで exec できるようにしました。session-manager-plugin は必要です。 exec

Mackerel Advent Calendar 2020 8日目の参加記事です。 2020年11月に、Amazon Lightsail Container というサービスがリリースされました。 dev.classmethod.jp 最低月額 $7 で、コンテナを気軽に(ロードバランサー込みで！) Amazon Lightsail 上にデプロイできるというものです。普通に AWS で Fargate のコンテナとロードバランサー(ALB)を動かすと最低でも$25/月程度はかかってしまうので、これはお手軽でよさそうですよね。 ということで、この Lightsail Container を Mackerel で監視してみましょう。 Lightsail Container の実体は? なにはともあれ、Ligtsail Container に環境変数を出力する Web アプリケーションをデプロイし

Amazon ECS でタスクの構成定義に使う task definition をリポジトリで管理する場合、JSON 形式で取り扱うことが多いと思います。 ECS デプロイツールである ecspresso でも、task definition は環境変数等を展開できる記法があるものの、基本的には JSON ファイルとして扱っています。 これは AWS コンソールで作成した task definition を aws describe-task-definition や ecspresso init コマンドでファイルとして取り出して利用することを前提としているためで、これを YAML や別の形式で扱うことは考えていません。 ところで、実際に ECS でそれなりのサービスを運用すると、task definition JSON の管理で悩むことが増えてきました。 JSON は人間が編集するのに

おかげさまで各所でご利用頂いている(模様の) Amazon ECS デプロイツール ecspresso ですが、リリースしてからもうすぐ3年になりますし、ここで一部非互換の修正を入れた v1 を出そうとしています。 非互換な点は少ないのでほとんどの方にはそのまま使って頂けると思いますが、下記を確認した上で v0.99.x を試して頂いて、もし何か問題があればフィードバックを頂けると幸いです。 (2020-10-30 追記) v1.0.0 をリリース済です。 github.com (2020-09-25 23:00 追記) Homebrew で 0.99.x がインストールできるようになりました。 tap ecspresso@0.99 by mashiike · Pull Request #9 · kayac/homebrew-tap · GitHub $ brew install kaya

Webアプリケーションパフォーマンスチューニングコンテスト ISUCON http://isucon.net/、記念すべき10回大会の予選に参加して、あと3チーム100点弱の差で不通過に終わりました。悔しい！ チームメイトは会社の同僚の @acidlemon (ISUCON 3の出題、ISUCON 4, 7 のチームメイト), @mackee_w (macopy, 実はチームを組んだのは初) です。 序盤から中盤 ベンチを回して MySQL が重いねー(いつものことだ) と把握 acidlemon estate の範囲検索になっているカラムを = 条件で取れるように 0〜49999 -> 0, 50000〜100000 -> 1 のようにクラスわけ(verify がたまにコケるのを解消できず取り込めず interpolateParams=true (server side prepare

要約 GitHub Actions に Amazon ECS デプロイツール ecspresso と AWS Lambda デプロイツール lambroll を簡単にインストール action を用意しました。 steps で以下の指定をするだけです。(Linux 環境専用です) - uses: kayac/ecspresso@v0 - uses: fujiwara/lambroll@v0 もうちょっと詳しく これまで GitHub Actions の action は基本的に Node で書く必要があったのですが、やりたいことはバイナリをダウンロードして展開してコピーするだけなのになんで Node を書かないといけないのか……(Linux以外の環境を考えると仕方ないとはいえ)、と面倒くささが先に立って、これまで action を作らないままでした。 が、先日 Composite Run

先日、Amazon Kinesis Data Firehose が任意の HTTP エンドポイントに対しての配信機能をサポートしました。 aws.amazon.com 従来の S3 / Redshift / Elasticsearch Service などのマネージドなリソースに対してデータを配信する機能に加えて、自分で作った HTTP(s) のエンドポイントに対しても Firehose からデータを投げ込んでくれる機能です。 Amazon Kinesis Data Firehose now supports data delivery to Datadog 既に Datadog や New Relic へもマネージドでデータを配信できていて、それらに送りたいデータはとりあえず Firehose に流しておけば、実際の送信やバッファリングやリトライは Firehose が面倒を見てくれると

あるところに、ひとつの Web サービスの本番環境が 20 個以上の Terraform state で管理されているリポジトリがありました。 おもに AWS 上で動いている、大変年代物かつ巨大なモノリスのサービスです。最初は何もコード管理されていない状態から徐々に Terraform を導入したのですが、その際に「一度に全部管理はできないから、徐々に Terraform 化していこう」という方針で管理を始めたところ… 新機能を追加するのでそのリソースを別 state で管理 改修があるのでそれらのリソースを別 state で管理 を繰り返すうちに、中に数個程度しかリソースがない state がどんどん増殖し、いつの間にやら20個以上になってしまったという状態です。ちなみにリソース定義は合計で 500 程度ありました。 さすがにここまで分割されてしまうと相互参照はできないし、VPC / S

Amazon ECS デプロイツール ecspresso と AWS Lambad デプロイツール Lambroll で、設定ファイル中に tfstate (Terraform state file)の値を検索して使えるようにしました。 これまで面倒だったところ ecspresso ではサービスとタスク定義、lambroll では関数定義を JSON で用意します。 その JSON の中では {{ env "FOO" }} のような記法で環境変数を展開してから読み込む機能があります。 デプロイや環境ごとに可変になる部分を、デプロイ時に環境変数によって外から与えることで定義ファイルをいちいち更新しなくていいという作りになっています。 しかし、たとえば ecspresso のサービス定義には以下のように、subnet, security group, LB target group などの I

SRE NEXT 2020 という、国内初の SRE に特化したカンファレンスで基調講演をご依頼いただいて、「Webサービスを1日10回デプロイするための取り組み」を話してきました。 sre-next.dev speakerdeck.com これまでいろいろ発表はしてきましたが、基調講演というのは初めてで、さて何を話したほうがいいのか悩みました。とはいえ自分は基本的に技術でなにかを解決する話しかできないので、かなり現場寄りの話です。いつもどおり。 時間の関係でいろいろ省略した部分があるのですが、懇親会で聞かれた CircleCI に移行して増えたコストの話については LobiのCIをJenkinsからCircleCIに移行したはなし - KAYAC engineers' blog にあるとおり 数万円程度だったCI関連費用は、およそ2倍の十数万円になりました。 ぐらいなので、Jenkins

先日えいやと書いた AWS Lambda のデプロイツール lambroll ですが、これと公開済みの bash layer を使うとかなり気軽に(雑な) shell script を Lambda で実行できて体験がよかったので書いておきます。 AWS Lambda のミニマルなデプロイツール lambroll を書いた - 酒日記 はてな支店 ちょっとしたものをLambdaで書くの億劫さのほうが強かったけど、bash layerとlambrollを使ったら雑shell scriptをホストで書いてるのに近い感じになり、顧客が本当にほしかったもの感があるなこれ— fujiwara (@fujiwara) 2019年11月13日 今回はとある理由で ECS のサービス内のタスクを定期的に入れ換えたかったので、aws ecs update-service を一発実行する、という要件。やりたい

3行で シンプル/ミニマルな Lambda のデプロイツール lambroll を書いてるよ Lambda API 以外は極力触らないやつです 既存 function の移行も簡単です 開発の経緯 AWS Lambda を管理、デプロイするのに数年来 Apex を使っていましたが、最近更新がないと思っていたら案の定というか、残念ながら No longer maintained となってしまいました。 で、代替を探したのですが… Lambda管理、Apexがお亡くなりになってServerlessかSAMになるんだけど、本当は関数だけdeployできればよくて(IAMとか関連リソースはTerraformでやるんで)、それなら裏でCloudFormationが動くようなのじゃないシンプルなのがいいなあ。作れば作れるけどデプロイツールばっかり書くことになるな…— fujiwara (@fujiwa

ecspresso は筆者が開発している Amazon ECS 用のデプロイツールです。 github.com 最近 AWS DevDay Tokyo 2019 の「第1回 AWS Fargate かんたんデプロイ選手権」でも紹介していただいて、気をよくして最近あれこれ機能追加をしていたのでそのご紹介です。 speakerdeck.com 分かりやすい導入記事をクラスメソッドさんの blog で書いていただきましたのでこちらもどうぞ。 dev.classmethod.jp 設定ファイル生成機能 ecspresso init で、既存の ECS サービスの情報を引っこ抜いて定義ファイルを生成し、そのまま ecspresso deploy できるようになりました。(v0.11) README の Quick Start にもあるように、region, cluster, service, con

技術評論社 WEB+DB Press vol.111 の連載 Perl Hackers Hub に、「AWS X-Rayによる分散トレーシング……マイクロサービスのボトルネック，障害箇所の特定」という記事を書きました。 WEB+DB PRESS Vol.111 作者: 松田明,y-yagi,佐藤建太,夜道,村田賢太,伊藤英明,見川孝太,新井剛,関陽介,海老原圭吾,長田洸明,大原壯太,藤原俊一郎,松本宏太,末永恭正,久保田祐史,牧大輔,笹田耕一,竹馬光太郎,池田拓司,はまちや2,竹原出版社/メーカー: 技術評論社発売日: 2019/06/24メディア: 単行本この商品を含むブログを見る 内容は1月にあった YAPC::Tokyo の発表をベースにしたものです。 sfujiwara.hatenablog.com YAPC での発表をしたときの印象で、どうも分散トレーシングはそこまでメジャーじゃ

Amazon ECS のタスク定義には、タスク内のコンテナの起動と終了の順序を制御する依存関係が定義できます。 docs.aws.amazon.com アプリケーションのコンテナと、アプリケーションが依存しているミドルウェアのコンテナがあった場合、依存を定義すると タスク開始時にミドルウェアが起動してからアプリケーションが起動する タスク終了時にアプリケーションが停止してからミドルウェアが停止する というような制御が可能です。 graphviz による可視化 しかし依存関係が複雑になると、JSON で文字列で書いただけでは実際にどう依存しているのかがよく分からないし、間違ってループを作ってしまうと起動できないので事前に確認したい、ということで可視化してみました。 これはとあるアプリケーションタスクの依存関係を、task definition の JSON から graphviz 用の .d

拙作の pull 型デプロイツール Stretcher をご利用中のかたに大切なお知らせです。 Amazon S3のAWS署名バーション2が、2019年6月24日をもって廃止されます dev.classmethod.jp Stretcher v0.x は Amazon S3 からのファイル取得に AdRoll/goamz を利用しており、このライブラリは Signature V2 を使用しているため、2019年6月24日以降 S3 からのファイル取得に失敗するようになります。 現状でも Signature V4のみサポートしているリージョン (us-east-2など) に対して実行すると、以下のようなエラーメッセージで失敗することが確認されています。 Load manifest failed: cannot detect valid credentials or region ということで

2019年1月26日に開催された YAPC::Tokyo 2019 にて、「Perlでも分散トレーシングしたい！ - AWS::XRayによる解析とその実装」というタイトルの最後で発表してきました。 yapcjapan.org 発表資料はこちらです。 speakerdeck.com ほとんどのクラウドベンダーやマネージドサービスで Perl SDK が提供されていない昨今ですが、AWS X-Ray を Perl で使いたいがために AWS::XRay を書いたよ、例として ISUCON 8 本選問題を解析してみたよ、という話です。 X-Ray は分散システムでなくても (従来型の RDBMS を使うだけの Web アプリケーションでも) パフォーマンス解析に有用で、使い始めるのに手間もないので興味を持ってもらえた人がいたら幸いです。 会場で挙手してもらった感じでも分散トレーシング自体それほ

とあるネットワーク(Web)サーバがありまして。 graceful restart できない graceful stop はできる 処理中のものは全て処理し終わってから終了する 再起動は数秒で完了する という性質のものを、稼働中に再起動するとダウンタイムがでてしまうのをなんとか誤魔化したかったのです。 最初は nginx から proxy しているところで、繋がらなかったら何秒かおいて何回までリトライ、みたいな設定ができないか探したんですが見つからず、HAProxy を調べたら以下のような設定でできたのでメモ。 frontend absorber mode tcp default_backend upstream bind *:9999 backend upstream mode tcp server localhost localhost:8888 weight 1 retries 10

いつもお世話になっている WEB+DB PRESS誌の vol.108 に、18周年記念エッセイを寄稿しました。2018年12月22日発売です。創刊18周年おめでとうございます。 これまで WEB+DB PRESS には Perl Hackers Hub (vol. 71) と、特集 (vol.94) で技術記事を書かせていただきましたが、まさかエモい文章を求められるとは。どういう経緯での人選なのかは知るよしもありませんが… 普段カンファレンスなどでも技術の話しかしないので、引き受けようかどうしようかちょっと迷ったのですが、(中を読んでいただければ分かるとおり) こういうお誘いには乗っておくべきだということで快諾しました。 いただいたお題が「私が限界を感じたとき」というもので、普段は「人生なるようにしかならないよ」と適当に生きているのでちょっと困りました。WEB+DB PRESS & 限界

Perl Advent Calendar 2018 11日目のエントリです。 最近、新しく書きはじめるもので Perl を使うことはめっきり減っているのですが、それでも仕事のいくつかのプロジェクトのメイン言語が Perl だったり、リリースした CPAN モジュールでまだまだ需要があるものはメンテが必要です。 ということでちょくちょく Perl も書いているので、今年自分がリリースした CPAN モジュールと update の変更点をまとめておきたいと思います。 Fluent::Logger おなじみ Fluentd へログを送信するためのモジュール。2011年にリリース以来、継続的にメンテナンスしています。2018年の変更は、エラー時に即座にリトリライするためのオプション追加でした。 0.27 2018-06-19T07:52:56Z Add retry_immediately opti