AWS Week in ReviewとSRE Weekly読んでて、自分の備忘録用のメモもこんな感じにまとまっていると良いだろうかと思い、試してみることにしました 44smkn Week in Review - November 14, 2022 - 1クール続けるブログ
これ始めて2週目で既に遅延している
まあでもゆるくやっていくのを目標としているのでそれでもヨシ
- Article
- メルカリShopsの注文システム安定化の歩み - mercari
- Kubecost Open Sources OpenCost: an Open Source Standard for Kubernetes Cost Monitoring
- All-in-One, Integrated Front-End Toolchain Rome Released V10, Dubbed First Stable Release - infoq
- Amazon EKS now supports Kubernetes version 1.24
- Composite availability: calculating the overall availability of cloud infrastructure
- Podcast / Radio
Article
メルカリShopsの注文システム安定化の歩み - mercari
マイクロサービス群のorchestrationをGCP Workflowsでやっているんですね。Workflows使ったことないですが、AWSで言うStepFunctionsという認識をしています。
冒頭読んで、もしかしてSagaの補償トランザクションの話かなと思ったんですが違ったようです。
「不整合の検知をできるようにする → 運用の中でカバーしきれなかったエラーのパターンやAPIが見つかる → 地道に改善を続けてほぼすべてのパターンがハンドリングできるようになる」という流れでした素敵。
Kubecost Open Sources OpenCost: an Open Source Standard for Kubernetes Cost Monitoring
kubecost自体はオープンソースではなくて、kubecostの中のコスト配分エンジンをオープンソース化したものがOpenCostみたいですね。
この記事に加えて OpenCost Product Comparison – Kubecost を見ると分かりやすいです。
OpenCostにはDashboardは含まれないそうです、prometheusのメトリクスを吐いてくれそうです。そう考えるとDatadogも使えそう。
それを踏まえて、AWS and Kubecost collaborate to deliver cost monitoring for EKS customersの記事でインストールされているのは kubecostの方であると。
tierを上げたかったらmarketplaceで買えますよってことですかね多分。
Freeだと15日間のretentionしかないのでちゃんと使うには課金が必要そうな雰囲気。ただ最初の30日間は無料とのこと。
https://www.kubecost.com/pricing/
All-in-One, Integrated Front-End Toolchain Rome Released V10, Dubbed First Stable Release - infoq
JaveScript周りのツールチェインは種類とその中での選択肢が多くてややこしいなと思っていました。
それを1つにまとめようとする壮大なツールとして、romeというのがあるんですね。
Rust書き換えて初めてのstable releaseということで、ここから盛り上がってくるんでしょうか?
Amazon EKS now supports Kubernetes version 1.24
v1.23 と v1.24 はほとんど期間開かなかったですね。確認したらおよそ3ヶ月間でした。
Topology Aware HintsでAZ跨ぎの通信量が減るのが期待できそうですね。
- dockershimとお別れ
- v1.24以降新しく追加される BetaAPI は今までと違いデフォルトで有効にはならない
- Topology Aware Hints
- more...
Composite availability: calculating the overall availability of cloud infrastructure
アプリケーションを構成する全ての異なるサービスを組み合わせた可用性 - composite availability
を計算する必要があるよね、という話。これを意識すると、よりresilientなシステムを設計することができて、その結果ユーザ体験が良くなるんではとのことでした。
自分たちで運用するサービスのSLOを決めるときも、この composite availability
以上には出来ないと思うので、プロダクトの要求する可用性がそれよりも高いのであれば、設計自体も見直す必要があるのだよなと思いました。
この記事の例だと、Google Cloudのサービスが説明に使われていたので、AWSでも例を一つ取って計算してみます。記事に書かれているSerialのパターンで。
SLAはここを参考: https://aws.amazon.com/legal/service-level-agreements/
.9999 * .9999 * .999 * .999 = 0.9978... ≒ 99.78%
Podcast / Radio
内山昂輝の1クール!#408
冒頭にあった休んだ時にストック使うべきかどうかという話。
内山さんが新型コロナウイルスに感染してしまったため、昔に収録したストックが放送された先週。「ピンチヒッターで人が来たほうが面白いんじゃないか」と話されていた。
それ聞いて思い出したのは、おぎやはぎのメガネびいきにて、おぎやはぎのお二人が欠席してゲスト予定のchelmicoとトンツカタン森本、アルピーでやってた回。
そう考えるとスリリングで面白いのかもしれないけど、ピンチヒッター側のプレッシャーがすごそう。
普段テレビでニュース観ないので、サッカーの情報はほぼ内山さんからしか入ってこない。
今回もワールドカップの話をしてくれていた。「いつもと時期違うんですよね」の一本槍で、この前美容師さんとの会話乗り切った。ありがとう。
ちょろいのリスナーも美容師さんから振られたうたプリの話を3枚くらいの手札で乗り切ってた気がする。