2021年振り返り

2020年振り返り

仕事

初めての転職という自分にとっての一大イベントを経験した。それからまだ一年も経っていないが、今まで経験したことのない濃密な時間を過ごしたように感じる。リモート勤務は継続しているものの、事業ドメイン・組織形態・技術スタックなど、逆に言えば他のすべてが変わった。「転職してみてどう?」という質問に一言で答えるなら、「よかった」。

Ubie 株式会社に入社していた

Ubie 株式会社に SRE として転職して一ヶ月経ったので、転職動機から転職後どうかまで書いてみる。まだ一ヶ月、ではあるが楽しく働けている。

2020年振り返り

仕事

コロナ禍でワークスタイルは大きく変わらなかった。これまで稼働時間の 1/3 程度 WFH していたのが、すべて WFH になった。結果、自分はどちらかといえば物理出社したい気持ちがあることが分かった。自分にとっての通勤とは、家から会社まで徒歩で行けるぐらいの距離だったので、通勤で消耗しないことは前提ではある。来年も、普通に物理出社できる状況になるとは考えにくいので、在宅業務環境には気を配り、積極的に投資していく。

Cross-certificates の整理

cross-certificates は https://itkq.jp/blog/2020/06/20/x509-chain/#クロス証明書 で触れたが、最近混乱したので整理する。RFC 5280 によれば cross-certificates の定義は次の通りで非常にシンプルである。

Cross-certificates are CA certificates in which the issuer and subject are different entities. Cross-certificates describe a trust relationship between the two CAs.

先の記事での署名関係は以下であった。この例では、USERTrust CA が「クロスルート証明書」で、USERTrust CA をトラストアストアに持っていない古いクライアントのために AddTrust CA root が USERTrust を署名し、トラストチェーンを構築できるようにするものだった。互換性を考慮してこうなっている。

Kubernetes を始めた

動機

最近趣味でつくる Web サービスは、AWS 上のサーバレス構成 (典型的には CloudFront + API Gateway + Lambda + DynamoDB) にしていて、コスパがめちゃめちゃ良く不満はない。が、Web 以外のワークロードも雑に動かしたいときがあり、できればなるべく安く済ませたい。ランタイムとしてはやはり Docker コンテナになるんだろうけど、ECS Fargate は安くなったものの個人的にはまだ高くて使いたくない。結局ランニングコストを避けられないのなら、コストを抑えつつ、勉強も兼ねて Kubernetes ってやつを触ってみたくなった。仕事ではまったく使わないものの、Kubernetes 自体は学生時代に少し学んだり触ったことがあった (後輩が研究室のインフラを K8s にして運用してた) ので、概念とかは知っているつもりだった一方、自分で運用したことはなかった。

一見不可解な TLS 証明書失効

この記事は、所属する会社の社内ブログに投稿した内容を一部改変したものです。

遭遇した事象

Prometheus と https://github.com/prometheus/blackbox_exporter を使って TLS サーバー証明書の有効性と有効期限を網羅的に監視しています。最近 blackbox_exporter が blog.cookpad.dk:443 の証明書の期限が切れている、と報告してきました。しかし同時に blackbox_exporter は TLS 接続には成功している、と報告していたのです。確認のため、Chrome で https://blog.cookpad.dk/ にアクセスしてみると、問題ありませんでした。Firefox でも同様でした。次に手元の MacBook Pro から cURL してみます。

2019年振り返り

仕事

2年目 (新卒1.8ヶ月) で引き続き SRE グループで色々をやった。今年は組織やチーム体制が変わったり、メンバーが別のプロジェクトに一時的に参加することになったりということが起きて、これは自分にとってはじめてのことだった。結果、去年までしっかりと理解できていなかった ECS 周りや、自前のバッチ処理システム、非同期ジョブ実行システムといった基盤も運用したり改善することも業務のスコープとなった。基盤勉強会という勉強会を何度かやって大枠をつかんだ後は、業務で必要に応じてコードを読んだり PR を出す過程で理解していった。まだ Fargate は多くのユースケースで実用段階ではなく、大半のコンテナは EC2 で動かす必要があり、それゆえに EC2 インスタンスの管理は ASG や Spot Fleet を使いつつもある程度自前でカバーしていかなければならず、そのためのシステムが多数あることを知って驚いた。このあたりは最近 ASG の機能が増えたり、今後 ECS がよくなっていくことで、いくつかのシステムが不要となりシンプルになっていく可能性はある。

英会話を始めて1年弱で辞めた

少し長くなってしまったがその経緯をまとめた。

第4回 WSA 研究会に参加した

開催概要: https://websystemarchitecture.hatenablog.jp/entry/2019/02/26/100725

自分の発表

とくに手持ちの実装や実装構想といったものがなかったため、最近よく考えていたカオスエンジニアリングについての整理を試みた。Netflix による “Chaos Engineering” ペーパーでは、すでにカオスエンジニアリングと同じようなことを Google や Amazon といった企業はすでにやっていることを知っていてそれをカオスエンジニアリングと名付けたと書いてある。その起源は明らかに「レジリエンス」のキーワードに関係していて、レジリエンスエンジニアリングという体系化された学問があることを知った。

Slack 上で AWS への単純な bot 攻撃に対処する

業務で使っているインフラ (AWS) に対して、たまに日本のリソースに対して海外の IP からスパムリクエストや明らかな攻撃が来ることがある。リクエスト元 IP が分散していない場合は IP ベースでブロックで十分である。ブロックするレイヤーはいくつかあるが、最近だと VPC の NACL で ban することが多い。NACL の操作を誤ると事故になりかねないので、業務ではセカンドオピニオンも取り入れつつ操作している。攻撃が判明する度に VPC のコンソールを開きつつチャットで誰かの意見を求めるというのは非効率なので、なんらかのソフトウェアを書くことでいい感じにしたいと思っていた。