Amazon ECS の古いタスク定義を断捨離する "tdtidy" という隙間家具 OSS を作った | はったりエンジニアの備忘録
自分は Amazon ECS のデプロイに ecspresso を利用することが多いのですが、頻繁にデプロイする環境だと 1 年で数百を超えるタスク定義が作られます。直近の数世代はロールバックする可能性があるので残しておきたいのですが、さすがに数か月前のリビジョンに戻すことはないため不要なものは断捨離したいと思っていました。 そういうリクエストが多かったのか、以前はタスク定義を非アクティブにすることしかできませんでしたが、今年の 2 月についに削除できるようになりました。 Amazon ECS が非アクティブなタスク定義リビジョンの削除をサポート さらに AWS が管理する Containers Roadmap のプロジェクトを眺めてみると、Issue #1967 でタスク定義にライフサイクルを追加してほしいというリクエストが挙がっていました（この Issue を作ったのは中の人っぽいので
我々は Kubernetes の何を監視すればいいのか？
freee では仮想マシンのインフラ監視に Mackerel を使っていますが、Kubernetes を使っているところは前例にとらわれずゼロベースで見直そうとしています。現状は Elastic Stack と Mackerel のハイブリット構成になっています。 Elastic Stack による Kubernetes モニタリングシステムの紹介 - freee Developers Blog どの SaaS を使うかを決める前に、そもそも Kubernetes の何を監視すればいいのか？ というところから考え直しています。宣言的なマニフェストにより Kubernetes が自律的にあるべき状態を保ってくれるのであれば、これまでの監視とは異なってくるはずです。 監視の観点として、ここでは通知レベルを用いて次の 3 つに分類します。 None: メトリクスは収集するが通知しない Notic
クラウド会計ソフト freee を使って家から一歩も出ることなく確定申告を終わらせた！ | はったりエンジニアの備忘録
みなさんはもう確定申告を終わらせましたか？ 2018 年は副業解禁が大きく取り上げられ、はじめて確定申告をするという方も多いのではないでしょうか。 自分は freee の正社員エンジニアとして働きながら、2017 年から個人事業主としても活動しています。 freee の中の人でありながら、ユーザーとしても普段から freee を愛用しています。そのあたりの経緯は「2017 年から個人事業主として開業します」をご覧ください。 今年は 2 回目の確定申告でしたが、タイトルにあるとおり 家から一歩も出ることなく確定申告を終わらせました！ 去年は顧問税理士さんにお願いしたので、自分で確定申告をするのは実は初めてです。 会計 freee を使って今年の確定申告が終わりました！ 電子申告だったので 2/15 よりも早く申告でき、しかも自宅ですべて済みます。電子申告オススメです！ https://t.c
GuardDuty が検出した脅威をいい感じに Slack へ通知する | はったりエンジニアの備忘録
AWS re:Invent 2017 で発表された脅威検出サービスの GuardDuty はもう試されましたか？ 発表されたその日に有効化してみましたが、さっそく意図せずオープンになっていたポートへの攻撃が検出されました。幸いポートスキャンされただけで実害はありませんでしたが、GuardDuty で検出されなかったら気づくことはなかったと思います。 ところで、GuardDuty が検出した脅威は AWS Management Console で確認できますが、メールや Slack でプロアクティブに通知する機能はありません。 AWS あるあるですが、通知したければ自分で仕組みを作る必要があります。 いつも参考にさせてもらっている Developers.IO の「GuardDuty を設定してメンバーアカウントを招待してみた」にもこんな感想がありました。 いまの状態だと、毎日 GuardDu
Kubernetes で意図的に障害を起こしたらどうなるのか？ | はったりエンジニアの備忘録
Kubernetes を本格的に使っていくにあたり Kubernetes の裏側の仕組みを勉強しています。抽象化が進みブラックボックスになっているものを何となくの知識で運用するのは怖いからです。仕組みをちゃんと理解しているかどうかは障害時にはっきりと現れます。 というわけで、Kubernetes で意図的に障害を起こしたらどうなるのか試してみました。今回は特殊な Node 障害を想定して、Kubernetes のネットワークで重要な役割を担っている iptables のルールがすべて消えたという想定です。 なお、この検証で使った Dockerfile や Kubernetes の Manifest ファイルは GitHub で公開しています。 Docker イメージも Docker Hub の Public リポジトリにあるので、Kubernetes クラスタさえあればすぐに試すことができ
「まずは当たり前のことをやってから言え」 | はったりエンジニアの備忘録
この投稿は社内の Qiita:Team に書いた記事を加筆・修正したものです。 「まずは当たり前のことをやってから言え」 この言葉は前職でお世話になった先輩の言葉です。障害が起きたときに最後の砦と信頼されていたエンジニアの方です。 いま思うとこの言葉が自分のエンジニア人生をより良くしてくれました。 「信頼されるエンジニア = 技術力が高いエンジニア」とは限らない 以前は「信頼されるエンジニア = 技術力が高いエンジニア」だと思っていましたが、実際にはそうとは限りません（技術力が高いエンジニアを批判する意図はありません）。 社内で周りを見渡せば納得すると思いますが、多くの人から信頼を得ているエンジニアはこんな人ではありませんか？ 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い
AWS WAF のレートベースルールを試してみた | はったりエンジニアの備忘録
freee の開発チームは、ユーザーに安心して使っていただけるよう様々なセキュリティ対策を行なっています。 SRE チームも例外ではなく、セキュアなインフラを提供できるように日々努力しています。 その一環で、先月リリースされた AWS WAF のレートベースルールを検証しました。このレートベースルールを使えば、DDoS 攻撃やブルートフォース攻撃、パスワードリスト攻撃を自動的に遮断できます。 Protect Web Sites & Services Using Rate-Based Rules for AWS WAF 設定方法は Developers.IO の記事が詳しいので、そちらをご覧ください。 AWS WAF でレートベースのルールが作成可能になりました | Developers.IO レートベースルールとは AWS WAF のよくある質問から引用します。 レートベースのルールは、A
CodeBuild を使って AMI 作成の時間を大幅に短縮した | はったりエンジニアの備忘録
freee では「会計 freee」に始まり、「給与計算 freee」や「会社設立 freee」など全部で 5 つのサービスを提供しています。また、サービス間で共通している機能はマイクロサービス化されているので、インターナルなサービスも含めると数多くのサーバが動いています。 サービスの特性に合わせてミドルウェアやプログラミング言語を選んでいるので AMI を共通化することが難しく、サービスの成長に伴って AMI の数も増えていました（起動時に Cloud-init でゼロからセットアップするやり方だと時間がかかりすぎるため採用できません）。 AMI の数が増えると管理コストがバカになりません。特に、Linux カーネルなどに脆弱性が見つかるとすべての AMI を作り直す必要があります。 freee では Packer と Ansible を使っているので構築自体は自動化されていますが、それ
「Hey Siri, デプロイおじさんに電話して」 Lambda と Twilio でワンコールデプロイをやってみた | はったりエンジニアの備忘録
「Hey Siri, デプロイおじさんに電話して」 Lambda と Twilio でワンコールデプロイをやってみた この記事は AWS Lambda 縛り Advent Calendar 2015 の 18 日目 & Twilio Advent Calendar 2015 の 19 日目の投稿です。 みなさんのチームではどのようにデプロイしていますか？ ワンクリックデプロイはもはや当たり前、ChatOps が進んでいるところだと Hubot でデプロイしているかもしれません。でも、映画「バック・トゥ・ザ・フューチャー」の世界では 2015 年は未来の日。もっとクールなデプロイ方法があっても良さそうです。 今回は Lambda と Twilio を組み合わせて、電話するだけでデプロイできる ワンコールデプロイ を実装してみました。 Siri を使うと手を動かす必要すらなく「Hey Siri
3 か月で AWS 認定を制覇したので合格の秘訣をまとめてみた | はったりエンジニアの備忘録
6 月ごろから AWS 認定資格を取るために勉強していました。 AWS は仕事でもプライベートでも利用しており、そのスキルを客観的に証明したいと思ったのがきっかけです。 AWS 認定には 3 つの分野と 2 つのレベルがあり、全部で 5 つの試験があります。 自分は次の順番で受験し、ちょうど 3 か月で制覇しました。 2015/06/25 : AWS 認定ソリューションアーキテクト - アソシエイト 2015/07/23 : AWS 認定デベロッパー - アソシエイト 2015/08/06 : AWS 認定 SysOps アドミニストレーター - アソシエイト 2015/08/27 : AWS 認定ソリューションアーキテクト - プロフェッショナル 2015/09/24 : AWS 認定 DevOps エンジニア - プロフェッショナル 余談ですが、認定証には国ごとの合格者の通し番号が振ら
インスタンスタイプによって SSD の性能が変わるのか調べてみた | はったりエンジニアの備忘録
JAWS-UG Meguro #0 のハッシュタグを追いかけていると @yoshidashingo さんがこんなツイートをされていました。 インスタンスディスクのSSD、インスタンスファミリーによって性能差あったんだ... #jawsmeguro — 真吾 (@yoshidashingo) May 22, 2015 インスタンスストアの SSD はどれも一緒だと漠然と思っていたので驚きました。ドキュメントを読んでみると SSD の TRIM 機能をサポートしたことにより書き込み性能が向上しているとのこと。 TRIM については、このページに詳しい説明がありました。 Trim 命令の功罪 | Logitec データ復旧技術センター 気になったことは手を動かして調べてみることを心がけているので、さっそくベンチマークを取ってみました。 ベンチマークの諸条件 OS: Amazon Linux AM
AWS 権限管理のベストプラクティスについて考えてみた | はったりエンジニアの備忘録
AWS は Management Console や API ですべて操作できます（Direct Connect など一部例外もあります）。データセンターの物理的なセキュリティなどは AWS が責任を負うところで、ユーザーはまったく意識する必要はありません。 その代わり、OS やミドルウェアの管理、アプリケーションの設計や実装、適切な権限管理などはユーザーが責任を負うところです。 今回はあまり取り上げられないけど、すごく大事な権限管理についてまとめてみました。自分が仕事で関わっているプロダクトで権限管理を見直すときに調べたことをベースにしていますが、もっと良いプラクティスがあればぜひ教えてください。 AWS アカウントは使わない 普段の運用で AWS アカウントは使いません。 AWS アカウントとは、最初にサインアップするときに作られるアカウントです。 このアカウントは Linux で言う
CloudWatch のカスタムメトリクスで JVM の GC を監視する | はったりエンジニアの備忘録
JVM 上で動くアプリケーションを運用するには GC に気を配る必要があります。 GC をうまくチューニングするためには、まずは現状を知ることが大切です。 GC の統計情報は jstat -gcutil で取得することができます。試しに Jenkins のプロセスを見てみます。 $ pid=`sudo jps | grep jenkins | awk '{ print $1 }'` $ sudo jstat -gcutil ${pid} S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 57.68 21.33 66.26 99.51 73 0.179 4 0.271 0.450 この統計情報を定期的に取得してビジュアライズすれば GC の傾向がつかめます。この AWS 全盛期に昔ながらの RRDtool は使いたくないので、今回は CloudWatch でビジュ
オンプレミスから AWS に移行して変えた 3 つのこと
7 月に開催された「JAWS-UG 三都物語 2014」でも発表したとおり、自分が関わっているプロダクトをオンプレミスから AWS に移行しました。 JAWS-UG 三都物語 2014 に登壇しました 移行して 2 ヶ月ほど経ちましたが、目立った障害もなく安定した運用を続けています。スライドでも少し触れていますが、これまでのやり方を大きく変えるキッカケにもなりました。 今回は「オンプレミスから AWS に移行して変えた 3 つのこと」と題して、社外に公開できる範囲でご紹介します。 稼働中のサーバに変更は加えない いわゆる Immutable Infrastructure の考え方を取り入れました。最初は流行りに乗りたかったという気持ちが大きかったのですが、今では昔のやり方にはもう戻れません。 オンプレミスでは本番稼働中のサーバにログインして何か変更するということが当たり前に行われていました
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
