CSE 138: Distributed Systems
From the beginning of this year, I started to take lecture courses of undergrad distributed systems course at UC Santa Cruz (CSE 138) by Lindsey Kuper. It consists of 23 lectures (you can see the schedule of topics from here) and recently I’ve finished all of them. I’m not a student at UCSC but due to the COVID-19 situation, all these lectures were delivered online and are available on YouTube. So
Waypointとは何か
Hashicorpの2020年冬の新作 Waypoint (リリースブログ)に関してドキュメントなどをざっと眺めてみたので最初の印象をちょっと書いてみる．ちゃんとしたレビューは @copyconstruct の記事 Waypoint とか読むのが良い．毎度のことながらドキュメントやガイドはかなりちゃんとしたのがあるので使い方とかはそっちを読んだ方がいい．以下に書くのはざっくりした個人の感想（ちなみにもう一つのBoundaryに関してはZero Touch Productionとは何か に軽く書いた）． What is Waypoint Waypointは，KubernetesやNomad，Amazon ECS，Google Cloud RunといったPlatformの上にBuild，DeployとReleaseの一貫したWorkflowを実現するツール．使ってる言語やそのパッケージ方法や，
Infrastructure as Dataとは何か
最近GCPから登場したKubernetes YAMLのPackage managerであるKptは「Infrastructure as Data（Configuration as Data）」という考えかたを基礎としてそれを推し進めようとしている．それ以外にもKubernetesのEcosystemには（明示はされていなくても）この考え方が中心にある．Infrastructure as Codeとは何が違うのかなど歴史を振り返りつつまとめてみる． （指針はBorg, Omega, and Kubernetesという論文にあるが「Infrastrcuture as Data（Configuration as Data）」という言葉を明確に定義した文章はない．この記事はReferencesに挙げるいくつかのPodcastにおける@kelseyhightowerの発言や，それに反応する@bgra
なぜMicroservicesか?
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
Service meshとは何か
Microservicesの世界においてService meshは大きなキーワードになった．KubeCon 2017やKubeCon 2018 EUにおいても多くのセッションをService mesh（もしくはその代表格であるIstio）が占めており注目の高さも伺える．もちろんMicroservicesを進めるMercariにおいても導入を検討しており今後重要なコンポーネントの1つになると考えている．本記事ではそもそもなぜService meshという考え方が登場したのか，なぜ重要なのか? その実装としてのIstioとは何で何ができるのか? について簡単にまとめてみる． 参考文献 Service meshを一番理想的な形でサービスに使い始めその考え方を広めたのはLyftだ（と思う）．LyftはIstioのコアのコンポーネントであるEnvoyを開発しそれを用いてService meshを構築
Kubernetes上でgRPCサービスを動かす
Kubernetes上でgRPCサービスを動かすことが多くなってきている．が適切にロードバランスをする，リクエストを落とさずサービスをデプロイするためにいくつか注意することがあるので簡単にまとめておく． 以下の2つを意識する． Kubernetes ServiceはL4のLoad balancer（LB）であること gRPCはコネクションを使いまわすこと KubernetesのPodは死んだり作られたりを繰り返す．KubernetesのPodにはそれぞれ内部IPがアサインされるが，このIPはPodが新しく作成される度に変わる．IPが変わってもPodにアクセスするためにKubernetesではServiceをつくる．ServiceはPodを抽象化しVirtual IP（VIP）を提供する．VIPを使うことでPodのIPが変わってもPodにアクセスすることができる． VIPはNetwork i
Golangのcontext.Valueの使い方
Go1.7でcontextパッケージが標準パッケージに入りしいろいろなところで使われるようになってきた．先日リリースされたGo1.8においてもdatabase/sqlパッケージなどでcontextのサポートが入るなどますます重要なパッケージになっている． “Go1.7のcontextパッケージ”で書いたようにcontextは「キャンセルのためのシグナルの受け渡しの標準的なインターフェース」として主に使われる．ある関数やメソッドの第1引数にcontext.Contextが渡せるようになっていればキャンセルを実行したときにその関数は適切に処理を中断しリソースを解放することを期待する．これはパッケージの作者とその利用者との間のある種の契約のようになっている（パッケージ側でgoroutine作るなというパターンもここで効いてくる）． これだけではなくcontext.Contextインターフェースに
SREとしてMercariに入社した | SOTA
1月16日よりMercariにてSRE/BSE（Backend System Engineer）として働いてる． これまではとある会社で社内向けのPaaSエンジニアとして働いてきた（ref. PaaSエンジニアになった）．PaaSの目標である「アプリケーション開発者の効率を最大化」を突き詰めながら少人数のチームでいかにScalableなプラットフォームを構築するかに注力してきた．Cloud FoundryやDockerといったインフラの最前線とも言える技術やアーキテクチャに触れ，かつその中で自分の技術的な柱である自動化に取り組むことができたのは非常に刺激的で自分に大きなプラスになった． その一方でPaaSというプラットフォームはその性質上サービスそのものからは中立的になることが避けられない（だからこそScalabilityを実現できるのだが）．よりサービスに近い部分，サービスの成長に直結す
Writing An Interpreter In Goを読んだ
Thorsten Ballによる“Writing An Interpreter In Go”を読んだ． 技術界隈のブログを見ているとたまにSteve Yeggeの「If you don’t know how compilers work, then you don’t know how computers work」という言葉に出会う．その度に学生のときにコンパイラの授業を受けなかったこと後悔し，社会人になって挑戦しようとして挫折したことを思い出して悲しい気持ちになる．@rui314さんのCコンパイラをスクラッチから開発してみたを読んではかっこいいなと思いつつ僕には無理だなあと心が折れていた． どの言語を書いていてもコンパイラ（もしくはInterpreter）は切っても離せないものであり内部の動きがどうなっているかを知っておきたいという欲求はプログラマーなら誰しもあると思う（少なくとも僕に
2016年振り返り
最初に今年やったことなどをつらつらと書いてみる． 2月．Dave Cheneyが中心となりGo1.6のRelease Partyが世界各地で開催されることになった（Go 1.6 release party）．東京でもやりたかったのでOrganizerとなりHatenaのオフィスを借りて開催した．8月のGo1.7のリリース時は特に世界規模でやる流れはなかったがフォーマットだけは借りて再びHatenaのオフィスで開催した．この時リリースの概要をまとめたスライドを作ったが@bradfitzがそれを改変して別のMeetupの発表資料に使ってくれた嬉しかった．2017年2月にリリース予定のGo1.8のリリース時は再び世界規模でやるかってのをDaveと話したのでぜひ参加してください． 5月．みんなのGo言語の執筆を主に行っていた．自分はコマンドラインツールに関する章を担当した．今まで発表やブログ記事の
Systems Performanceを読んだ
Brendan Greggによる“Systems Performance: Enterprise and the Cloud”を読んだ． Linux（Solaris）のパフォーマンスの分野でBrendan Greggという名前を聞いたことがあるひとは多いと思う．名前を知らなくてもが書いているブログやカンファレンスでの発表資料を見かけたことはあると思う．また彼が開発したFlame Graphにお世話になってるひともいるのではないか（ref. GolangでFlame Graphを描く）．とにかくパフォーマンスに関して常に先端にいるひとである． そんな彼がSystems（ここでいうSystemsとはCPUやメモリといったハードウェアとKernelやOSといったソフトウェアを指す）のパフォーマンスについて内部のアーキテクチャーを含め徹底的に解説したのが本書である．面白いに決まってる． 本書の根底
GolangでAPI Clientを実装する
特定のAPIを利用するコマンドラインツールやサービスを書く場合はClientパッケージ（SDKと呼ばれることも多いが本記事ではClientと呼ぶ）を使うことが多いと思う．広く使われているサービスのAPIであれば大抵はオフィシャルにClientパッケージが提供されている．例えば以下のようなものが挙げられる． https://github.com/aws/aws-sdk-go https://github.com/Azure/azure-sdk-for-go https://github.com/PagerDuty/go-pagerduty https://github.com/hashicorp/atlas-go 特別使いにくい場合を除けば再実装は避けオフィシャルに提供されているものを使ってしまえばよいと思う（まともなものなら互換性などをちゃんと考慮してくれるはずなので）．一方で小さなサービ
Golangにおけるinterfaceをつかったテスト技法 | SOTA
最近何度か聞かれたので自分がGolangでCLIツールやAPIサーバーを書くときに実践してるinterfaceを使ったテスト技法について簡単に書いておく．まずはinterfaceを使ったテストの基本について説明し次に自分が実践している簡単なテクニックをいくつか紹介する． なおGolangのテストの基本については @suzuken さんによる「みんなのGo言語」 の6章が最高なので今すぐ買ってくれ！ 前提 自分はテストフレームワークや外部ツールは全く使わない．標準のtestingパッケージのみを使う．https://golang.org/doc/faq#Packages_Testing にも書かれているようにテストのためのフレームワークを使うことは新たなMini language（DSL）を導入することと変わらない．最初にそれを書く人は楽になるかもしれないが新しくプロジェクトに参入してきたひ
sync.ErrGroupで複数のgoroutineを制御する
Golangの並行処理は強力である一方で同期処理を慎重に実装する必要がある．“Go 言語における並行処理の構築部材”にまとめられているようにGolangは様々な方法でそれを実装することができる．実現したいタスクに合わせてこれらを適切に選択する必要がある． この同期処理の機構として新たにgolang.org/x/sync/errgroupというパッケージが登場した．実際に自分のツールで使ってみて便利だったので簡単に紹介する． 使いどころ 時間のかかる1つのタスクを複数のサブタスクとして並行実行しそれらが全て終了するのを待ち合わせる処理（Latch）を書きたい場合にerrgroupは使える．その中でも「1つでもサブタスクでエラーが発生した場合に他のサブタスクを全てを終了しエラーを返したい」（複数のサブタスクが全て正常に終了して初めて1つの処理として完結する）場合が主な使いどころである． 実例
Go1.7のSubtestsとSub-benchmarks
Go1.7ではSubtestsとSub-benchmarksという機能がtestingパッケージに導入される．これを使うとテスト関数/ベンチマーク関数の中にテスト/ベンチマークを定義できるようになる．テストの場合はテストに階層を持たせることができ，ベンチマークの場合はTable Driven的にベンチマークを記述することができるようになる．さらに一連のテスト/ベンチマークに対して共通のsetupとtear-downを持たせることもできる． テストの場合はTable Driven Testsで十分なことも多く恩恵は少ないかもしれない．それよりもベンチーマークで効果を発揮することが多い． 例えば以下のように異なる設定値を使ってFooのベンチマークをとるとする．今までであればそれぞれ設定値ごとにベンチマーク関数を準備する必要があった． func BenchmarkFoo1(b *testing.
Go1.7のcontextパッケージ
Go1.7ではgolang.org/x/net/contextがcontextパッケージとして標準パッケージに仲間入りする．そしていくつかの標準パッケージではcontextパッケージを使ったメソッド/関数も新たに登場する．contextパッケージは今後さらに重要な，Gopherは普通に扱うべき，パッケージになると考えられる．本記事ではそもそもcontextパッケージとは何か？なぜ登場したのか？なぜ重要なのか？どのように使うべきか？についてまとめる． contextパッケージが初めて紹介されたのは2014年のThe Go Blogの記事 “Go Concurrency Patterns: Context”である．この記事ではなぜGoogleがcontextパッケージを開発したのか，どのように使うのか具体的な検索タスクを例に解説されている．まだ読んだことがない人はそちらを先に読むと良い． co
GopherCon 2016でLTした
GopherCon 2016でLTをした．@tenntennさんがやった通常トーク（50分）はなかなかハードルが高いがLTは初めの一歩として良いと思う．来年もDenverで再び開催されることがアナウンスされているので来年以降に発表するひとのためにどんな感じだったかを簡単に書いておく． モチベーション 発表スライドを見てもらえばわかるが特に新しい話をしたわけではない．日本のミートアップなどで話したこと，ブログに書いたことを英語にしただけにすぎない（ただ実演デモをするという挑戦はした）． 「大御所たちと同じステージで喋る機会を逃すのはもったいない」（ちなみに当日のLTは僕の次がRobert Griesemer氏でその次がBrad Fitzpatrick氏だった！），「日本のGo界隈にこんなやつおるでってのを知ってもらいたい」というモチベーションで発表した．あとなんとなく自分の中でここでぶっ込ま
Golangの新しいGCアルゴリズム Transaction Oriented Collector（TOC）
http://golang.org/s/gctoc Goの新しいGCのProposalが出た．まだProposal段階であり具体的な実装はないが簡単にどのようなものであるかをまとめておく． GoのGCはGo1.5において単純なStop The World（STW）からConcurrent Mark & Sweepへと変更され大きな改善があった（詳しくは“GolangのGCを追う”に書いた）．先の記事に書いたようにGo1.5におけるGCの改善は主にレイテンシ（最大停止時間）に重きが置かれいた．数値目標として10msが掲げられGo1.6においては大きなヒープサイズ（500GB）においてそれを達成していた． GCの評価項目はレイテンシのみではない．スループットやヒープの使用効率（断片化の対処）なども重要である．Go1.6までのGCではそれらについて大きく言及されていなかった（と思う）．例えばスル
GolangでFlame Graphを描く
アプリケーションのパフォーマンス問題の解決やチューニングで大切なのは問題のコアやボトルネックに最短パスで到達することである． 基本的なパフォーマンス分析の入り口はアプリケーションのスレッドがon-CPUで時間を消費しているかoff-CPUで時間を消費しているかを理解するところから始まる．on-CPUの場合はそれがuserモードかkernelモードかを特定し，さらにCPUプロファイリングによってどのcode pathがCPUを消費しているのかの分析に向かう．off-CPUの場合はI/OやLock，pagingといった問題の分析に向かう． Flame Graphはon-CPUでのパフォーマンスの問題が発覚した時に行うCPUプロファイリングを助ける．どのcode pathがボトルネックになっているのかを1つのグラフ上で理解できる．本記事ではFlame Graphとは何か? なぜ必要なのか? を解
Known unknowns
“Systems Performance: Enterprise and the Cloud” をずっと読んでいる．この本はNetflixのBrendan Gregg氏がJoyent時代に書いた本である．その名の通りLinux（とSolaris）のシステムのパフォーマンスの本である（とにかく一つ一つが丁寧かつ深く解説されておりページをめくるごとに学びしかないのでパフォーマンスに関わるひとは今すぐ読むと良い）． この本で一貫して現れてくる，通底するのが，known-knowns，known-unknownsそしてunknown-unknownsという概念である．元ネタはDonald Rumsfeld 氏の会見でのコメントだが（cf. There are known knowns），複雑なシステムのパフォーマンスの重要な原則を集約している．良い概念なので簡単に紹介する． それぞれをパフォーマン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
