はてなブックマーク

最近「いかに運用作業に手を抜くか」というのを考えているので、なんとなーくアウトプットしてみようと思う。 運用作業とは? 運用作業はゼロが理想だけど、そーもいかない 運用を頑張りすぎてしまうエンジニア pospomeはどうしているか? まとめ 運用作業とは? 自分が想定する "運用作業" というのは機能開発に関係ない作業全般である。 例えば以下の作業は "運用" にカテゴライズしていいと思う。 ソフトウェアのバージョンアップ ユニットテストの実装・保守 問い合わせ対応 リファクタリング 運用作業はゼロが理想だけど、そーもいかない 自分は運用作業がゼロになるのが理想だと思っている。 可能であれば、機能開発にすべての工数を投じて、自身が開発するプロダクトを進化させていきたい。 ただ、運用作業をゼロにするのは不可能である。 ソフトウェアのバージョンアップは定期的にしなければいけないし、リファクタリ

以下の記事でマイクロサービスアーキテクトグループについて紹介しているが、 SREチームのアウトプットをここにまとめる。 www.pospome.work アウトプット一覧 DMMプラットフォーム ゼロから始めるKubernetes運用 課題と改善 DMMプラットフォームのマイクロサービス戦略 オーナーシップの落とし穴 マイクロサービスとk8sにおける責任境界設計とリソース管理 マルチテナント型EKSを活用したプラットフォームエンジニアリングの光と闇 マルチテナントKubernetes環境のKubernetes External Secrets が非推奨になるので External Secrets Operatorへ移行した話 社内で提供しているマイクロサービスの参考実装について Amazon EKS に Node Local DNS Cache を導入した際にハマった話 GKEでCloud

最近「マイクロサービスって大変だな」と感じることが多いので、書いてみた。 単なる感想です。 pospomeのマイクロサービス歴 面倒なのは技術ではない モノリスだと厳しい 楽しくもある 宣伝 pospomeのマイクロサービス歴 以下の企業で7年ほどマイクロサービスに携わっている。 DeNA（ゲームプラットフォーム） メルカリ（認証認可基盤） DMM（DMMプラットフォーム） DeNA, メルカリではサーバサイドエンジニアとして仕事をしていて、 DMMではプラットフォーム事業本部という120人のエンジニアが在籍する開発組織のアーキテクトとして仕事をしている。 それぞれの会社で開発の規模感、開発体制、自分の役割などが異なるので、 直接比較できないが、やはりポジション的に今のDMMが一番大変だなーと感じる。 面倒なのは技術ではない マイクロサービスというと "分散トランザクション" とか "通信

自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、 最初に比べると組織がそれっぽく拡大したこともあり、 ここ最近テックリードを立てる機会が増えてきた。 一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。 DMMプラットフォームのマイクロサービスアーキテクトグループとは? pospomeがテックリードに求める役割 技術領域をリードする プロジェクトマネージメント 他チームとのコミュニケーション チームメンバーの評価 なんだかんだで総合力 pospomeがテックリードに求めない役割 ピープルマネージメント よく分からない政治的なコミュニケーション 適切なチームサイズについて 新規チーム設立を考慮する場合 おまけ：テックリードに求める役割と適切なチームサイズ以外のあれこれ No.2 の重要性 立場が人を作

DMMプラットフォームではアラートモニタリングにDatadogを利用しているが、 最近Sentryを導入しようと思っている（自分のチームだけ2年前くらいから先行して導入しているけど、良さそうなので組織全体で利用しようと思っている）。 この記事はDMMプラットフォームのエンジニアにSentryを紹介した際のドキュメントを加筆修正したものである。 Sentryとは? なぜSentryを導入するのか? Sentryの機能紹介 エラートラッキング機能 1. エラーをグルーピングしてくれる 2. グルーピングしたエラーごとに対応優先度を決めることができる 3. グルーピングしたエラーごとにリクエスト情報、クライアント情報を可視化してくれる 4. エラーごとに対応記録（Activity）を管理することができる 5.Datadogでは補足しづらいエラーを可視化することができる アプリケーションモニタリン

"Cloud Operator Days Tokyo 2022" の登壇資料です。 トークなしのスライドだけでは内容が伝わりきらないとは思いますが、一応公開しておきます。 20minの発表にも関わらず、"ゼロから" というテーマにしてしまったので、話をまとめるのに苦労しました。 結果的に広く薄い内容になってしまったのですが、 なんとなーく自分がやっていることを伝えることはできたかなと思います。 ここで紹介している課題は "ゼロから" という関係上、初期のものが多いですが、 現在は別の課題があったり、実は改善しきれていない課題もあったり、問題は山積みです。 speakerdeck.com DMMプラットフォームのマイクロサービスアーキテクトチームではサーバサイドエンジニアとSREを募集中です。 興味のある方は連絡ください。 これまだ募集しています。GKEとEKS（GCPとAWS）両方触りたい

エンジニアのスキルレベルチェックという文脈で System Design Interview が気になっていたので、自チームのエンジニアにやってみた。 System Design Interview とは? どうやって実施したのか? 実際にやってどーだったか? エンジニアとしてのレベル感がそのまま結果として出る傾向にある コミュニケーション能力 得意分野と不得意分野が明確に出る 出題する側も難しい Spannerへの圧倒的な信頼 まとめ System Design Interview とは? ググれば出てくるので説明は割愛します。 どうやって実施したのか? チームメンバーには System Design Interview のことは伏せて、 ミーティング開始時に「System Design Interview をやります」って感じで始めたので、 System Design Intervie

k8s のCDツールがいくつかあるので、それらの特徴についてまとめる。 一応CDツールの定義は"k8sにWebアプリケーションをデプロイするツール"を想定しているが、 k8sにおけるデプロイはマニフェストファイルを apply することなので、 そういったものはすべてCDツールとみなして調べた。 すべてのツールをちゃんと調べたわけではないので、ものによってはサラッとした紹介になっている。 Flux Tekton(Tekton Pipeline) Jenkins-X PipeCD GCP Cloud Deploy AWS Code Pipeline Spinnaker Pipeline & Stage 動的なパイプライン Managed Delivery Spinnaker を使いこなせるか? ArgoCD Single Source of Truth(SSOT) 複雑なCDパイプラインは作

DatadogのMonitorでSlackに通知を送る際にUserGroupへのメンションをセットしようと思ったが、 以下のようにSlackのUserGroupのIDで指定する必要があるのでUserGroupのIDを取得した。 <!subteam^12345> https://docs.datadoghq.com/integrations/slack/?tab=slackapplicationus#-mentions-in-slack-from-monitor-alert Datadogのドキュメントには以下のSlackのAPIを利用してIDを取得するように書いてある。 usergroups.list method | Slack 一応APIを使ってみたが、usergroup名でフィルタリングできなさそうなので、結局APIからIDを取得することは諦めた。 すべてのusergroupを取得し

チームメンバーと1on1をしているので、そこで自分が取り組んでいることをまとめておこうと思う。 なぜ1on1をしているのか? 自分がメンティーだった頃 自分がメンターの立場になった 1on1の頻度 1on1で何を話しているのか? 目標の進捗確認とフィードバック 目標の変更 他チームへの貢献 仕事の話 キャリアパス 完了したタスクに対するフィードバック メンティの熱量を失わせないようにする pospome以外の人との1on1の案内 メンターとメンティーの距離感 さらなる改善に向けて 意味のある1on1になっているか? なぜ1on1をしているのか? 以下の記事もあるとおり"マイクロサービスアーキテクトチーム"というチームを立ち上げたからである。 People Managementをする必要がある。 inside.dmm.com 自分がメンティーだった頃 今でこそメンターとしてチームメンバーと1

自分は以下の書籍で各レイヤ構造に対する実装を Go で解説しているが、 書籍を書いてからも異なるパターンを色々と試行錯誤していた。 pospome.booth.pm 書籍内ではユーティリティ系の実装を配置するパッケージとして "コアレイヤ" というレイヤの話があるが、 それを廃止してドメインレイヤ内にサブドメインごとにパッケージを配置した方がよいかもしれないと思った。 コアレイヤの存在がきっかけとなったが、 最終的には "ドメインレイヤの実装をサブドメインごとに管理する" という考えに落ち着いた。 具体的なパッケージ構成について 汎用的な実装をドメインレイヤに配置する違和感 util パッケージと infrastructure パッケージの違い ドメインの優先順位と開発 注力するドメインの変化と実装の移行 まとめ 具体的なパッケージ構成について ここでは具体的なパッケージ構成について説明す

GCP Artifact Registry に push したら以下のエラーが発生した。 権限の設定ミスっぽいエラーだけど、それっぽい権限を付けてもエラーは解消されなかった。 denied: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "xxx" (or it may not exist) エラーの原因は Artifact Registry へのリクエストを認証するためのコマンドである "gcloud auth configure-docker" が間違っていることだった。 Container Registry では以下のように認証するが・・・ gcloud auth configure-docker https://cloud.google.com/container-re

社内slackで以下の記事と同じようなことを悩んでいるというメッセージがあった。 2018年の記事ではあるが、自分もGoを利用し始めた頃に考えたことがあるので、この記事に書かれている内容をベースに改めて自分の意見をまとめておく。 ここに書く内容が正しいかどうかは自己判断して欲しい。 tyru.hatenablog.com なぜ golint でエラーになるのか? 元の記事の "Interface を定義することを考える" という解決策について 現実的に起こりうるリスクを考える まとめ 宣伝 なぜ golint でエラーになるのか? 上記の記事には "golint でエラーが出る" という内容があった。 なので "そもそもなぜ golint でエラーが出るのか?" を考える必要がある。 エラーになる理由は以下である。 github.com パッと読んだ感じ以下の2つになると思う。 1. クラ

社内slackでGoについて質問されて、それなりに長文で回答したのでその内容を加筆修正したものをブログに残しておく。 質問内容としては以下のイメージ。 RubyだとRailsがあり、MVCを利用することになるが、Goだとそこらへんはどうなるのか? Go初心者なのでGoのモダンなアーキテクチャとフレームワークについて教えて欲しい。 これ系の質問はGo経験者であれば「あーこれなー」と思うだろーし、 Go初心者のときに一度は悩んだことがあるだろう。 なので、個人的な意見を残しておく。 自分の意見が正しいかどうかは自己判断して欲しい。 結論 アプリケーションアーキテクチャの複雑化とMVCフレームワーク システムアーキテクチャの複雑化とフルスタックなフレームワーク マイクロフレームワーク 改めて質問内容を振り返る pospomeが考えるGoのフレームワーク選定 pospomeが考えるGoのアーキテク

最近マイクロサービスアーキテクチャが抱える課題を解決するために色々やろうとしているのでまとめてみました。 マイクロサービスアーキテクチャの採用 開発効率と疎結合な組織 開発効率と多様性 何をどこまでルール化するか 大規模なマイクロサービスアーキテクチャの難しさ マイクロサービスアーキテクト "認証認可 x ゼロトラストネットワーク x DDD x マイクロサービス" を扱うマイクロサービスアーキテクトチーム まとめ マイクロサービスアーキテクチャの採用 今さらマイクロサービスアーキテクチャ自体について自分が説明することもないのだが、 マイクロサービスアーキテクチャの目的の1つは "大人数で開発しても開発効率を落とさないこと" であると思っている。 普通に考えて "巨大なモノリスなシステムを大人数で触る" というアプローチでは限界があるだろう。 今ではモジュラモノリスという選択肢もあるので

技術書典7で"実装パターン"に関する書籍を販売します。 techbookfest.org 何の書籍なのか? ページ数と価格 技術書典後にBOOTHで販売しますが価格は上げます かんたん後払い対応します 目次 何の書籍なのか? 一言でいうと実装パターンに関する書籍です。 サンプルコードはGo言語ですが、内容としてはサーバサイド、クライアントサイドに関係なく役に立つものをピックアップしました。技術書典の当日は見本誌を用意する予定なので、是非手にとって内容をチェックしてみてください。 ページ数と価格 ページ数は67ページです。 価格は1000円です。 技術書典後にBOOTHで販売しますが価格は上げます 過去のものと同じようにBOOTHで販売します。 pospome.booth.pm ただ、当日技術書典7に参加する人への特典としてBOOTHで販売する際には価格を上げようと思っています。 前々回、前

技術書典で何書こうかなーと思ってなんとなくブログの記事を見直していたときに、 またなんとなーく実装系の記事をまとめてみようかなと思いました。 過去の記事とかは検索で引っかからない限り読んでもらえる機会ないと思いますし。 ちなみに過去に書いたものほど内容が正しいかどうかは保証できないので気をつけてください。 内容が正しいかどうかは自分自身で判断しましょう。 DDD&実装パターン Go言語に特化したやつ DDD&実装パターン"Goの"とか"golangの"と付いているタイトルもありますが、Goに限らず他の言語にも共通する内容だと思ったものはここにリストアップしています。 DDDとコードとしての正しさ - pospomeのプログラミング日記 decorator, presenter, exhibit という3つの実装パターンについて - pospomeのプログラミング日記 goddd とは何か?

こちらのイベントで"マイクロサービスにおける認証認可基盤" について話しました。 mercari.connpass.com 内部通信の認証ということで、なかなか外に出せない技術的なテーマかと思いますが、今回アウトプットする機会があったのでアウトプットしました。 発表資料はこちらです。 speakerdeck.com メルペイ認証基盤チームに興味のある方は以下の記事が参考になるかと思います。 興味があれば是非お話だけでも聞きに来てください。 www.pospome.work

こんな感じになる。 ポイントは -H で指定するヘッダーが複数の場合に改行することくらい。 # ab -n 1000 -c 1 -H 'Service-Type:1 Service-User-Id:117504418042902918542 Device-Id:79D0A481-56FD-4FB6-868A-5073F7ECC666 User-Id:120 Version:2.0.0 Os-Type:1' http://xxxxxx.com 実際にどのようなレスポンスを取得しているのかを確認したければ v オプションで確認可能。 v の後ろに 1 ~ 4 の数字を指定するだけ。 個人的には想定しているレスポンスかどうかを確認するために 最初は -n 1 -c 1 -v 4 で全ての情報を出力している。

以前ツイートした通り、 メルペイの認証基盤チームに興味を持ってもらうためにこの記事を書きました。 メルペイには"メルカリ、メルペイにおける認証認可の仕組みを構築すること"を目的にした認証基盤というチームがあります。高負荷でありながら高い可用性を要求され、システム仕様も複雑です。難易度の高いタスクがたくさんあるチームなんですが、興味ある人いますかね・・・?— pospome (@pospome) 2019年6月6日 この記事を読んで興味をもった方は是非応募してみてください。 応募方法とpospomeへの連絡方法は最後に記載しています。 メルペイ認証基盤チームとは? 認証基盤チームで経験できること 認証認可 高負荷 高可用性 セキュリティ 複雑な仕様 コミュニケーション ドキュメント 技術的負債の返済 英語 アプリケーションアーキテクチャ 認証基盤チームで経験しづらいこと アウトプット プロダ

技術書典6で"Go+Docker+CircleCI+GKE+Spinnaker"に関する書籍を販売します。 技術書典の当日は見本誌を用意するので興味のある方は実際に手にとって内容を確認していただければと思います。 techbookfest.org 前回は以下のサーバサイドアーキテクチャの書籍を出したのですが、 今回はWebアプリケーションのデプロイフローに関する書籍です。 pospome.booth.pm なぜデプロイフローの書籍を書いたのか? この書籍で学べること この書籍で学べないこと 価格 PDFのみ販売 Webでの販売 目次 なぜデプロイフローの書籍を書いたのか? ここ1,2年ほど「自分はアプリケーションが動く環境に対する知識がないなー」と思っていました。 Docker,Kubernetes,CI/CDをググりながらイジれはするものの、 自分で環境を構築したことはありませんでした。

ドメイン駆動設計 #1 Advent Calendar 2018の14日目を担当する@pospomeです。 今回はDDDとコードとしての正しさについて書いてみようと思います。 DDDは設計手法である コードとしての正しさ コードとしての正しさを見失う ユースケースの日本語を"そのまま"コードに落とし込もうとする 無駄にオブジェクト同士の結合度を上げる RubyのActiveRecordの正しさ コードとしてのメリット、デメリットを具体的に考えて解決する まとめ DDDは設計手法である DDD = ドメイン駆動設計 ですよね。 "設計"という単語が付いていることから分かる通り、DDDはあくまでソフトウェアにおける設計手法です。 そのためDDDの成果物は"コード"であり、DDDの目的は"コードの可読性を上げること"であると自分は考えています。 DDDが持つ"ビジネスを理解する", "ドメインを

Mercari Advent Calendar 2018 の13日目は株式会社メルペイ認証基盤チームの @pospome がお送りします。 メルカリのアドベントカレンダーで特定の実装パターンの網羅集みたいなやつを書こうと思ったんだけど、組み合わせ爆発でまとめきれそうにないな・・・。テーマ変えるか・・・。— pospome (@pospome) 2018年12月4日 実装パターンの網羅集が書けそうにないことに気づいた & 改めて考えると実装パターン自体が破綻している気がするので、 せっかくなら自分が使ったことのない機能を利用してみようかなと思いました。 そこで今回は"テストの並列実行"を使ってみました。 テストを並列実行してみる 現在時刻に依存するテストは失敗してしまう 現在時刻に依存するテストだけ並列化しない 現在時刻を引数に指定するかどうか 引数で現在時刻を指定する場合の実装例 現在時刻

技術書典5にて販売した "pospomeのサーバサイドアーキテクチャ" をBOOTHから購入できるようにしました。 以下から購入できます。 価格は技術書典と同じ1000円です。 booth.pm 技術書典に来てくださった方への特典として価格を少し上げたり、 内容を落としたりしようと思いました。 しかし、遠方のため行けない人がいたり、 予定があって行けない人がいたり、 行きたくても行けない場合もあるので、 特典というのも少し違うかなと思い、価格は据え置き、内容も同じという形で販売しました。 次の技術書典では当日来てくださった方向けの特典でも用意しようかなと思っています。 ちゃんとしたイラストを表紙にした物理本をプレゼントしたり、 一部の内容を落としたりしようかと。 落とす内容は独立して切り離せる内容にしないといけないので、次回はそれも考えて書く必要がありますね。

技術書典5にサークルとして参加することになったので、 書籍の詳細についてまとめました。 techbookfest.org [追記] BOOTHから購入できるようにしました。 pospome.hatenablog.com 書籍のざっくり情報は以下です。 書籍の目次はこちら サーバサイドのアプリケーションアーキテクチャに関する書籍 ページ数は155ページ PDF版のみ 価格は1冊1000円 購入していただけるとその場でQRコードが印刷されている紙を渡すので、そこからPDFをDLしてください。 サンプルコードはGo言語ですが、サーバサイドのアプリケーションアーキテクチャがメインなのでサーバサイドのアプリケーションエンジニアであればGo言語に関わらず役に立つはず かんたん後払いには対応していません 当日まで可能な限り内容を精査するので、内容が一部変更されるかもしれません。 当日は見本誌を用意するの

@a_suenami さんのこのツイートの Decorator, Presenter, Exhibit が気になったので調べてみた。 表示に関するデザインパターンは大きくDecoratorパターン、Presenterパターン、Exhibitパターンの3つがあります。で、Exhibitパターンが一番柔軟ですが小さいアプリでは一見複雑なので、Presenterパターンで始めて必要になったタイミングでExhibitパターンに移行するというのが一番僕は好きです。— すえなみ＠すえなみチャンス (@a_suenami) 2018年5月30日 なんか今調べてみたらちょっと僕の解釈間違っていたかもしれない https://t.co/wRe4DnFeUW— すえなみ＠すえなみチャンス (@a_suenami) 2018年5月30日 PresenterもExhibitもDecoratorパターンの一緒で、ど

自分は iota の使い所が分からなかった。 なんか事故りそうだし、明示的に値を宣言した方が分かりやすいような気がする。 で、こんなツイートをしたら・・・ #golang の iota 使った定数定義って、定数の並び順によって値が変わるから、なんか事故りやすい印象あるんだよな。誤って順番変えちゃいました的な。みんな使ってるのかな。iota 使わなくても設定する値を間違えたら結局事故るから、あまり気にしなくてもいーのかな。— pospome (@pospome) 2017年8月19日 tenntenn さんと kaneshin0120 さんに返信をいただいた。 DBに保存するような値は基本使ってないですね— tenntennʕ ◔ϖ◔ʔ ==Go (@tenntenn) 2017年8月19日 なるほど。理由としては「永続化される値だと事故るとデータの修正が発生して面倒」だからでしょうか? 個