はてなブックマーク

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

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を実現するツール．使ってる言語やそのパッケージ方法や，

GoogleのSREとSecurityによるBuilding Secure Reliable Systems という本の中で「Zero Touch Production (ZTP) 」という考え方が紹介されていた．これはインフラの権限管理やインフラの構築そのものの指針となる概念であり，自分がそうあるべきだとずっと思ってきた考え方でもある．これはどのような考え方なのか?をこれまでの歴史を踏まえて具体的なツールや事例とともにまとめておく． Zero Touch Production Building Secure Reliable Systems においてZero Touch Production (ZTP) は以下のように定義されている． The SRE organization at Google is working to build upon the concept of least

現職においてPlatform チーム（社内基盤チーム）として働き始めて2年近くがたった．このチームにおいて自分はTech Leadをメインに努めてきたが，同時にPlatformの「どのような機能を」「どのような優先度で」作るか? を決めるProduct Manager的な役割も果たしてきた（ちなみにTech Leadに関してはメルカリのテックリードが学んだ、HowよりWhyを重視することが大切なわけ で少し話した）．これは何度も失敗しながら悪戦苦闘しつつやってきたが自分たちなりのフレームワークをつくり実際に回すことができている． 未だに試行錯誤しているのでここで書いていることが正解だとは思っていないが，今後同じようにPlatformチーム的なことを始めるひとに向けて現状自分たちがどのようにやっているのかについて簡単にまとめておく（他の会社がどのようにやってるのかも聞きたいのでもし同じような

Platform EngineerとしてのPractice（2020年） 少し前にキャリアに関してインタビューを受けたが，振り返ってみると前職のCloud Foundryによる社内PaaSから現職におけるKubernetesによるMicroservices platformまでかれこれ5年にわたってPlatformの開発と運用に携わってきたことになる． 5年もやってるとPlatform engineer（Platfomer）として，特定の技術とはある程度中立的なところで習慣として当たり前にやっていることや日々の意思決定の基礎になる考え方みたいなものが出てくる．見ればわかるようにこれは何か特別な考え方とかではなくてどっかで見たことや聞いたことがあるものがほとんどだと思う．自分の中でゼロから生まれたものではなくて現在のチームと働いた経験や日々のインプット，これまでの失敗の総体でしかない． 現在

最近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

Competing with Unicorns: How the World’s Best Companies Ship Software and Work Differently The Agile Samuraiの作者でありSpotifyにおいてAgile CoachとEngineerを努めたJonathan Rasmussonによる本．本書はUnicornもしくはTech companyがどのようにチームをつくり，組織をスケールさせ，文化を作っているのかについて書いている．タイトルにUnicornとあり複数の企業を扱ってるように見えるが，基本的には作者のSpotifyにおける体験が基になっておりSpotifyの話が中心になっている． なぜMicroservicesか?ではMicroservicesの最終ゴールは組織にあると書いた．これは共通の見解（のはず）である一方で，Microse

2019年のアウトプットとインプットを簡単に振り返っておく． Working 業務でのチームとしてのアウトプットはMercari Microservices Platformの進捗（2019年）にまとめた．前年に引き続きPlatformの開発と運用を続けている． 昨年はAPI gatewayの開発など自分で手を動かすことが多かったが，今年は自分が具体的なプロジェクトを持ち自ら手を動かすことは意識的に少なくし，Tech leadとしてチームのアウトプットをどのように最大化にするか?ということを常に考えていた．技術的な視点や意思決定も時間的に影響範囲的により広く見るように意識し始めた（インプットも組織やチームに関連するものが多くなった）．見えやすいアウトプットは少ないが，プロジェクトを進めつつ，これまで曖昧だったPlatformのMissionは何かを明確に定義し，チームが拡大しても皆が同じ方

今年読んだ技術書籍やレポートなどをざっくりまとめてる．Infrastructure Engineer・Platfomerとして日々の業務に直結するものから1年くらいかけてやっていきたいと思っていることなどを中心に． Kubernetes 業務ではメインにKubernetesを使っているのでKubernetesに関わる書籍は発売されれば大体目を通すようにしている． 今年発売されたので良かったのはProgramming Kubernetes．この本はCRDやOperatorによってKubernetes nativeなアプリケーションを構築することにフォーカスしている．昨年のJapanContainerDaysでのMicroservices Platform on Kubernetes at Mercariでも話したようにKubernetesを使う大きな理由の1つはその拡張性にある．Kubebu

現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の

2018年のアウトプットとインプットを簡単に振り返っておく． Work 仕事で取り組んだことは全て以下のMercari Tech Conference 2018で発表させてもらった．前年から引き続きMercariのMicroservices化に向けた基盤の構築をしている． MTC2018 - Microservices Platform at Mercari 大きかったのは“API GatewayによるMicroservices化”で紹介したAPI gatewayのリリースそして@terryの“Mercari API: from Monolithic to Microservices”や@morikuniさんの“Listing Service: From Monolith to Microservices”で紹介されている「出品」というMercariの中でもとても重要な機能をMicrose

先日Japan Container Days v18.12の基調講演で話をさせていただく機会があった．内容としてはMercari のMicroservices Platformの基盤として「なぜ」Kubernetesを選択したか？ついて現状や今後の展望を踏まえて紹介をした． Microservices Platform on Kubernetes at Mercari 「なぜ」の回答としては，CRDやAdmission webhookといった拡張機構を使うことで今後起こりうる様々なWorkloadに特化したPaaSや抽象化レイヤーを書いていけるExtensibilityの高さとそのBuilding BlockとしてのEcosystemの強さを挙げた． このトークのExtensibilityの文脈で話したくて時間がなかったのが「Kubernetesがいかに我々の自動化に対する考え方を変えたか

Kubernetes YAMLの壁で述べたようにKubernetesのYAML管理はKubernetesユーザにとって長年の課題だ．コミュニティでは様々なツールが議論されてきた．先日SIG-CLIから登場したkustomizeは将来的にkubectlに統合される前提で開発されている+他のツールと比べても非常に筋が良い（と感じている）．本記事ではkustomizeが登場した背景とKustomizeを使って何ができるのかをまとめる． Declarativeであること Declarative ConfigurationはKubernetesの重要な機能の一つだ．KubernetesユーザはKubernetes APIに対してあるべきDesiredな状態を宣言（Declare）することでKubernetesはその状態になるように動き続ける．例えばユーザが「Podを5つ動かす」という状態を宣言すると

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サービスを動かすことが多くなってきている．が適切にロードバランスをする，リクエストを落とさずサービスをデプロイするためにいくつか注意することがあるので簡単にまとめておく． 以下の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

KubernetesでGPUを使う 一般的なWebアプリケーションと比較してMachine Leaning（ML）は複雑なインフラを要求する．Data processingを行う環境やModelのTraining/Validationを行う環境，実際にサービスからModelを利用するためのServingの環境といった複数の異なる環境が必要であり，WorkloadによってはCPUだけではなくGPUも必要になる．これらを効率的に扱うためのインフラを構築・運用するのは容易でなくGoogle and Uber’s Best Practices for Deep Learningにあるようにこれまで培われてきたDevOpsの知見を結集していく必要がある． このような複雑なMLのインフラとしてContainerとKubernetesが利用されることが多くなってきている．特に複数の環境間のPortabi

Kubernetes に入門しようする人を躊躇させる原因のひとつは間違いなくYAMLによる設定ファイルだろう．Kubernetesにアプリケーションをデプロイするとき，例えそれがシンプルなサーバーアプリケーションであっても，多くのYAMLファイルを手で記述する必要がある．初心者を慄かせるその大量のYAMLはよくwall of YAML（YAMLの壁）などと揶揄される． 初心者でなくてもKubernetesのYAMLは煩わしい．YAML自体は単なるKubernetes APIへのリクエストボディであり慣れてしまえば実はそんなに難しくない．しかし記述する内容のほとんどがBoilerplateであり何度も書いていると飽き飽きする（実際にはほとんどがコピペだが）．あるアプリケーションの開発環境と本番環境のYAMLファイルをいかに効率的に管理するかについて決定的な方法もない． そもそもKuberne

Go1.7でcontextパッケージが標準パッケージに入りしいろいろなところで使われるようになってきた．先日リリースされたGo1.8においてもdatabase/sqlパッケージなどでcontextのサポートが入るなどますます重要なパッケージになっている． “Go1.7のcontextパッケージ”で書いたようにcontextは「キャンセルのためのシグナルの受け渡しの標準的なインターフェース」として主に使われる．ある関数やメソッドの第1引数にcontext.Contextが渡せるようになっていればキャンセルを実行したときにその関数は適切に処理を中断しリソースを解放することを期待する．これはパッケージの作者とその利用者との間のある種の契約のようになっている（パッケージ側でgoroutine作るなというパターンもここで効いてくる）． これだけではなくcontext.Contextインターフェースに

1月16日よりMercariにてSRE/BSE（Backend System Engineer）として働いてる． これまではとある会社で社内向けのPaaSエンジニアとして働いてきた（ref. PaaSエンジニアになった）．PaaSの目標である「アプリケーション開発者の効率を最大化」を突き詰めながら少人数のチームでいかにScalableなプラットフォームを構築するかに注力してきた．Cloud FoundryやDockerといったインフラの最前線とも言える技術やアーキテクチャに触れ，かつその中で自分の技術的な柱である自動化に取り組むことができたのは非常に刺激的で自分に大きなプラスになった． その一方でPaaSというプラットフォームはその性質上サービスそのものからは中立的になることが避けられない（だからこそScalabilityを実現できるのだが）．よりサービスに近い部分，サービスの成長に直結す

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）は切っても離せないものであり内部の動きがどうなっているかを知っておきたいという欲求はプログラマーなら誰しもあると思う（少なくとも僕に

最初に今年やったことなどをつらつらと書いてみる． 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言語の執筆を主に行っていた．自分はコマンドラインツールに関する章を担当した．今まで発表やブログ記事の

Brendan Greggによる“Systems Performance: Enterprise and the Cloud”を読んだ． Linux（Solaris）のパフォーマンスの分野でBrendan Greggという名前を聞いたことがあるひとは多いと思う．名前を知らなくてもが書いているブログやカンファレンスでの発表資料を見かけたことはあると思う．また彼が開発したFlame Graphにお世話になってるひともいるのではないか（ref. GolangでFlame Graphを描く）．とにかくパフォーマンスに関して常に先端にいるひとである． そんな彼がSystems（ここでいうSystemsとはCPUやメモリといったハードウェアとKernelやOSといったソフトウェアを指す）のパフォーマンスについて内部のアーキテクチャーを含め徹底的に解説したのが本書である．面白いに決まってる． 本書の根底

特定の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でCLIツールやAPIサーバーを書くときに実践してるinterfaceを使ったテスト技法について簡単に書いておく．まずはinterfaceを使ったテストの基本について説明し次に自分が実践している簡単なテクニックをいくつか紹介する． なおGolangのテストの基本については @suzuken さんによる「みんなのGo言語」 の6章が最高なので今すぐ買ってくれ！ 前提 自分はテストフレームワークや外部ツールは全く使わない．標準のtestingパッケージのみを使う．https://golang.org/doc/faq#Packages_Testing にも書かれているようにテストのためのフレームワークを使うことは新たなMini language（DSL）を導入することと変わらない．最初にそれを書く人は楽になるかもしれないが新しくプロジェクトに参入してきたひ

PagerDutyのOn-callを一時的に自分にアサインするdutymeというツールを書いた 現在のチームではインシデント管理にPagerDutyを使っている．On-callはPrimaryとSecondaryの2人体勢でそれを1週間ごとにローテーションで回している．On-Callにアサインされている場合は夜中であれ日中であれPrimaryにアラートが飛ぶ（Primaryが反応できなければSecondaryにエスカレートされる）．そしてアラートを受けたら何かしらの対応を行う． これはうまく回っているが問題もある．業務中（日中）はPrimaryやSecondaryに関係なくチームメンバーはどんどんデプロイしたりProduction環境で作業をしたりする．そしてオペレーションやデプロイ対象のコンポーネントによってはアラートが発生してしまうことがある．つまり作業者に関係なくアラートがPrima

Golangの並行処理は強力である一方で同期処理を慎重に実装する必要がある．“Go 言語における並行処理の構築部材”にまとめられているようにGolangは様々な方法でそれを実装することができる．実現したいタスクに合わせてこれらを適切に選択する必要がある． この同期処理の機構として新たにgolang.org/x/sync/errgroupというパッケージが登場した．実際に自分のツールで使ってみて便利だったので簡単に紹介する． 使いどころ 時間のかかる1つのタスクを複数のサブタスクとして並行実行しそれらが全て終了するのを待ち合わせる処理（Latch）を書きたい場合にerrgroupは使える．その中でも「1つでもサブタスクでエラーが発生した場合に他のサブタスクを全てを終了しエラーを返したい」（複数のサブタスクが全て正常に終了して初めて1つの処理として完結する）場合が主な使いどころである． 実例