4年弱勤めた AWS を2022年3月末付けで退職します. 本日が最終勤務日です. 在籍期間中には多くの AWS ユーザーや同僚にお世話になりました. 感謝の気持ちを込めて、退職報告をしたためます. 基本的にはポエムなので、忙しい方は次のまとめセクションだけで十分だと思います. TL;DR 2022年3月末をもって AWS を退職します ネガティブな理由での退職ではありません. 挑戦こそ我が人生というやつです. 次は4月から日本のスタートアップ企業にて Software Engineer として働きます 本文読むのは面倒だけど質問がある方は本記事末尾の FAQ をあわせてどうぞ AWS 入社当時の思い出 当時 AWS Japan でサーバーレス スペシャリスト ソリューション アーキテクト (SA)1 を務めていた西谷さん2に誘ってもらい、2018年の5月末に入社しました. AWS 入社後

『手軽に作って壊してができる ECS Anywhere お試し環境が欲しい』、あるいは『ECS Anywhere で遊んでみたい気持ちはあるけどそれだけのために Raspberry Pi を買う1気にはならない』、という方向けの記事です. TL;DR x86_64 なラップトップが手元にあるなら… VirtualBox で VM を作ればサクッと試せる ただし VM はそこそこ重い M1 Mac なみなさまは… VirtualBox は残念ながら M1 Mac 未サポート というか ARM 未サポート お金を出せば Parallels で ARM な VM を作れる2ので、それも可 💸 VMware Fusion は残念ながら記事執筆時点で ARM 未サポート というわけで、本記事では Docker-in-Docker を利用して (M1 Mac でも) ECS Anywhere する手

Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション

トリのデスク 2020 勤め先が COVID-19 からの原則 Work from Home 方針となり、2020年は1月の出張明けからほぼずっと自宅で仕事をしています. というわけで自宅作業の生産性を高めるという (ありがちな)理由のもと、この1年で自宅の仕事用デスク周りを整えてきました. どんなものを買ったのか、使ってみてどうだったかなどをこの記事で紹介していきます. まずは結果から リビングのソファに座って MacBook Pro 13-inch で作業していた日々と比べると、人権の高まりを感じます. 今後改善していきたい点はまだ残されているものの、個人的には現状にけっこう満足しています. 以下、買ったものなどをつらつらと書いていきます. モニタ x 2 モニタは LG 27UD58-B という 27 インチ 4K モニタを2枚使っています. 会社貸与の MacBook Pro 13

プラットフォームの上でものを作るということ Amazon EKS Advent Calendar 2019 の最終日です. みなさまご存知の通り、AWS には Amazon ECS と Amazon EKS という2つのコンテナオーケストレーションに関するサービスがあります. ECS は2014年に発表された AWS ネイティブなコンテナオーケストレータ、EKS は OSS のコンテナオーケストレータである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました. 今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います. // 読んでくださっているみなさまをミスリードしないための DISCLAIMER 本記事の著者は AWS に勤めています. また、この記事には僕個人の意見や想いも強くこもっています.

AWS Fargate Advent Calendar 2017 の 24 日目です. 記事のアイデアを練り始めたときは「流量が安定しない Amazon SQS キューと AWS Fargate で動かす “lazy-worker” なコンテナってすごく相性良さそうですよね」という小ネタを書くはずだったんですが、気づいたらなぜかポエムになっていました. しかも図が一つもありません. お許しください. リリースされたばかりということで AWS Fargate とその関連機能について間違って理解している可能性もあります. 発見された方は Twitter とかで構わないので教えてもらえると嬉しいです. AWS Fargate で見られる夢 AWS Fargate は任意の Docker コンテナを一定の制約の範囲内で仮想マシンのプロビジョニングや管理なしに走らせてくれる夢のサービスです. どのへ

サーバーレス・アプリケーションの開発ツールチェーンとして AWS SAM まわりがいい感じに成長してきているのであらためて紹介します Serverless Advent Calendar 2017 の 15 日目です. 本記事ではサーバーレス・アプリケーションの開発ツールチェーンとして最近なかなかいい感じになりつつある AWS SAM (AWS Serverless Application Model) とその周辺を紹介しようと思います. 本記事は AWS 上でサーバーレスなアプリケーションを動かしたい オープンソースとしての公開も考えてたりする サーバーレスなアプリケーションも CI/CD に組み込んで継続的に開発・デプロイしていきたい 過去に CloudFormation で Lambda をデプロイしようとして血を吐きかけた というわけで CloudFormation は生理的にちょ

GitHub と AWS CodeBuild を連携させるサーバーレスなツールを作りました [中身編] 紹介編の続きです. 本記事では github-codebuild-integration の構成や実装などについて掘り下げてみます. このあと何回も github-codebuild-integration と書くと疲れそうなので、以下 gci と書きます. また、本記事中でコードやファイルに対して張られているリンクはすべて記事公開時点で最新の v0.1.1 のものです. 目次 gci リポジトリの中身の話 デプロイまわりの話 Amazon API Gateway じゃなくて Amazon SNS を選んだ理由 AWS SAM と node_modules の関係がエグい AWS Step Functions ええやん CloudFormation Lambda-backed カスタム・

チーム開発の開発環境として Docker + Vagrant を選択し続ける理由 Docker Advent Calendar 2016 の 25 日目です. Docker アドベントカレンダーとして書いているはずだったんですが、推敲と校正を重ねているうちに Docker というよりは VM とか開発環境とかの話が色濃くなってしまい、主役のツールが Vagrant になってしまいました. 謹んでお詫び申し上げます. 僕が所属する会社の事業の一つに Web/モバイルアプリの SI + 運用があり、その際の Web/API サーバー開発は macOS + Vagrant + VirtualBox (CoreOS) + Docker を社内標準のローカル開発環境(以下、開発環境)としています. 勉強会後の懇親会やコンサルティングを提供する場で良く質問されることの一つに「Docker for Ma

サーバレスアーキテクチャーって言葉が流行っているのでその近辺技術に触れてみたくてアプリを一本こしらえてみました. リポジトリは github.com/toricls/pingbot です. 何を作ったか サーバーレスな外形監視ツールです. 1 分ごとに任意の Web サイトに対して http/https リクエストを投げることで外形監視を行い、その結果を保存します. 前回チェック時と比較してステータスが変化した場合、Slack にその旨通知してくれます. 安価かつ安定して任意の Web サイトに対してヘルスチェック(死活監視)を行うことを目的として、AWS Lambda、Amazon CloudWatch Events、Amazon DynamoDB あたりを使っています. サーバーレスアーキテクチャーの構成要素として良く利用されるサービスですね. 管理画面となる Web アプリの方は R