はてなブックマーク

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

この記事は、所属する会社の社内ブログに投稿した内容を一部改変したものです。 遭遇した事象 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 してみます。 $ curl -v https://blog.co

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

開催概要: https://websystemarchitecture.hatenablog.jp/entry/2019/02/26/100725 自分の発表 とくに手持ちの実装や実装構想といったものがなかったため、最近よく考えていたカオスエンジニアリングについての整理を試みた。Netflix による “Chaos Engineering” ペーパーでは、すでにカオスエンジニアリングと同じようなことを Google や Amazon といった企業はすでにやっていることを知っていてそれをカオスエンジニアリングと名付けたと書いてある。その起源は明らかに「レジリエンス」のキーワードに関係していて、レジリエンスエンジニアリングという体系化された学問があることを知った。 レジリエンスエンジニアリングを調べてみると、最近の Web サービスにおける信頼性の考え方、SRE のエッセンスの一部が Safe

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

モチベーション サービスメッシュのための Side-car proxy として有名な Envoy proxy (以下 Envoy) がある。Envoy は Observability や Resiliency など便利な機能の他に、Fault Injection 機能を持つ。この Fault injection は、システム全体の可用性を向上させるためのシステム間通信の障害のエミュレートに使われるものであり、これは一般に Chaos Engineering や Resiliency Testing と呼ばれる。 最近 Chaos Engineering に興味があったため、Envoy を使った簡単な Fault Injection を試すことにした。Envoy で Fault Injection をするためには Fault Injection filter を利用する。Fault Inje

修論を書き終えたあたりから、春休みに何をするか考えていた。4月からソフトウェアエンジニアとして働き、主にインフラの仕事をする予定だったので、まとまった時間が必要かつ将来役に立ちそうなことを考えた。 ちょうどその頃に turingcomplete.fm を聞いて、OS を学びたい気持ちになった。そうして始めたのが MIT の 6.828: Operating System Engineering の授業である。JOS という xv6 ライクな小さい x86 OS のスケルトンが用意されており、必要な部分を実装していくことが課題である。シェルの動作までを完成させた後、最終課題としてパケット送受信かオリジナル機能を実装して終了ということになっている。 選択した理由 30日OS本も検討していて図書館で借りた。書くべきコードはインターネットですべて入手可能だったため、本を眺めてなんとなく分かった気持

この文章は、ハイパフォーマンスブラウザネットワーキングを読んで、改めて TCP/IP を自分の中で整理し、パフォーマンスに関する内容を簡単にまとめたものである。 情報通信ネットワーク特論を受講しておりタイミングが良かったという理由もある。 IP IP は、パケット交換によるデータ通信網を実現するためのプロトコルである。The Internet ができる前は、Hop-by-Hop（中間ノード間）で信頼性を確保していた。TCP/IP は、経路到達性と信頼性を IP と TCP の形で分離したプロトコルスイートである。この分離により、複雑なトランスポート機能はエンドシステムだけで行えるようになった。このような設計思想は End-to-End Principle と呼ばれる。 TCP TCP は コネクション指向であり、Go-back-N ARQ を基本とする輻輳制御プロトコルである。 コネクショ

開催概要: http://websystemarchitecture.hatenablog.jp/entry/2017/12/17/133301 きっかけ 元々のきっかけは、僕が酔っ払って適当にツイートしてたら、y_uukiさんにいい感じにされてた [Twitter] ことである。y_uuki さんとは一度リモートで会ったことがあったので、じゃあ物理で会いに行こうということになっていた。それとは別に、もともと WSA 研には興味があった。その理由は主に次の2つである。 Web サービスインフラの寿命 最近は Web サービスインフラの可能性について漠然と考えていた。近年、AWS, GCP をはじめとするクラウド、IaaS でサービスを構築することは当たり前になっている。そして、Heroku をはじめとする PaaS, さらには CaaS (Container as a Service) も

最近 TCP BBR congestion control comes to GCP – your Internet just got faster が話題になっていた．しかし，この記事を読んだ時点での自分の BBR についての知識は，「既存のものよりいい感じにしてくれる輻輳制御」ぐらいだった．これではまずいということで，BBR とはなんなのかについて，既存の輻輳制御にも触れながら，元の論文1 をメインにまとめた．自分が理解するための文書であるが，一応としての想定読者は，TCP が輻輳制御を行っていることを知っているぐらいの人である．TCP については，拙著の TCP/IP とパフォーマンス に短くまとめてあるので参照できる． 免責事項: TCP を深く研究しているわけではなく，間違いを記述している可能性があります．コメントで教えていただけると助かります． 概要 BBR (Bottlene

すべてがファイルというモデルの Linux (Unix) において、ファイル I/O (以降単に I/O と書く) を知っておいて損はない。 この記事では、基本的なファイルと関連する I/O について、対応する Linux システムコールも併せて説明する。 次回はこれらを実際に Linux 上で確認する予定。 ファイル Unix におけるファイルとは、普通「通常ファイル」のことを指し、バイトがリニアに並んだデータ (byte stream) のことである。 ファイル内のバイトは読み書きが可能で、指定されたバイトから開始する。この開始バイトはファイル内の「位置」と考えることができ、ファイルポジションまたはファイルオフセットという。 通常ファイルとは別に、スペシャルファイルというファイルとして表現されたカーネルオブジェクトがある。Linux では、スペシャルファイルとしてデバイスノード・名前付

これは、自分がプログラミングを始めた頃に読みたかった（読むべきだった）というつもりの文章である。 Unix の歴史 Linux 登場までの歴史を簡単にまとめた。省いているところも多い。 Unix の誕生 ベル研究所の Ken Tompson が、1969年に開発したゲーム用プラットフォームが起源である。当時はメインフレームで動く TSS が実験されていた (Multics) が、大規模で複雑なプロジェクトだった。 ベル研究所は Multics プロジェクトから脱退したが、彼らは対話的コンピューティングを必要としていた。その後ゲーム開発を可能にするプログラム（＝カーネル）が生み出された。これが Unix の元となった。Unix の語源は、Multics (Multiplexed information and computer system) を意識した UNiplexed Informat