CloudNative Days Tokyo 2020 #CNDT2020_A
K8sとTraefikでつくるマイクロフロントエンド
CloudNative Days Tokyo 2020 #CNDT2020_A
Mackerelにおける Cloud Nativeへの取り組みと チームへ与えた変化 / CloudNative Days Tokyo 2020
Mackerelにおける Cloud Nativeへの取り組みと チームへ与えた変化 / CloudNative Days Tokyo 2020
どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング
Platform チームの@deeeeeeeetです． Platform チームは2年前にMercariがMicroservicesの移行を始めたときに一緒に立ち上げられたチームです．Platform チームはMicroservicesを動かすための基盤や開発や運用のためのツールセットなど提供しています．立ち上げ時は自分を含めて2-3人で始まったチームですが2年が経ち10人を超えるチームにまで成長しました． チームのメンバーが増えるほど1チームとして動くには限界がきており，またMicroservices化が進めば進むほどチームの負う責任範囲も広くなりCognitive load (認知負荷) も高くなっていました．これらの課題を解決するために組織変更を行い，Platform チームを複数の専門性に特化したチームに分割しました． 本記事ではチームのデザイン，チームが分離しても独立性を保ちつつ
「ZOZO MLOps のチームリーディングとSRE(Engineering)」というタイトルで SRE Next 2020 に登壇しました
1/25(土) に開催された「SRE Next 2020」 という日本では初めて行われる SRE (Site Reliability Engineering) に関するカンファレンスに登壇しました。 2019年4月にチームを新規に発足してから、どのようにチームを率いて成果を上げ、社内の信頼を得てきたのか 、メンバーの成長を促してきたのか、について語りました。 https://docs.google.com/presentation/d/1zEkR9Dm_epg7fxOCFE-asBsUlHDozwObsBEGAILiqic/edit#slide=id.p1 [B6] ZOZO MLOps のチームリーディングとSRE(Engineering) 私は2019年4月にZOZOにMLOpsチームを作り、それから10ヶ月ほどチームをリードしてきました。 その10ヶ月の間にZOZOでは買収も含め色々
メルペイ社内ツールのお話 | メルカリエンジニアリング
Merpay Advent Calendar 2019の5日目です。 メルペイ社内ツールのお話をしようと思います。 “個人事業主の集まりかよ”と評されることもある、メルペイソリューションチームの一員である、vvakameさんが開発・管理しているツールやシステムの紹介をします。今まであんまり外に出したことがなかったので。 mercari/datastoreなどのオープンになっているものや、OSSへのPRなどの社外からも観測可能なものは今回は割愛します。 そもそも、ソリューションチームとは？ vvakame（TypeScript, Go, GraphQLなど）、sinmetal（GCPほぼ全部 最近Spanner）、orfeon（Dataflowなど）の3名で構成される、何かを適当にいい感じにするチームです。 メンバー募集中なので興味がある方は適当にアポイントを取ってください。Job Desc
今年読んだ技術書籍（2019年）
今年読んだ技術書籍やレポートなどをざっくりまとめてる．Infrastructure Engineer・Platfomerとして日々の業務に直結するものから1年くらいかけてやっていきたいと思っていることなどを中心に． Kubernetes 業務ではメインにKubernetesを使っているのでKubernetesに関わる書籍は発売されれば大体目を通すようにしている． 今年発売されたので良かったのはProgramming Kubernetes．この本はCRDやOperatorによってKubernetes nativeなアプリケーションを構築することにフォーカスしている．昨年のJapanContainerDaysでのMicroservices Platform on Kubernetes at Mercariでも話したようにKubernetesを使う大きな理由の1つはその拡張性にある．Kubebu
ポストモーテムにおける根本原因分析 - 夜は寝る
SRE Advent Calendar 2018、僭越ながら3日目を担当させていただきます、@kabaomeです。 勢いでカレンダーに登録しましたが、私は明示的にSREというポジションではなく、一アプリケーションエンジニアです。 半年くらい前にSRE本*1を読み、「こういうのやっていくゾ☆」と思い立って、社内で勝手にいろいろやっています。いまのところ怒られていません。 ポストモーテム、その中でもっとも重要であり難しい（と思っている）根本原因分析について、個人的見解を書いてみます。 TL;DR ポストモーテムやその根幹である根本原因分析の情報あんまない 根本原因分析の結論は「客観的」「単純」「制御可能」であるべき 根本原因分析はスキルだと思います、がんばっていきましょう ポストモーテム まずはポストモーテムについて簡単にご紹介します。 SREの皆様におかれましては常識だと思いますので、読み飛
Well-Architectedな組織を実現するためのチャレンジ
この記事は、CyberAgent Developers Advent Calendar 2018 13日目の記事です。 はじめまして、技術本部サービスリライアビリティグループ（以下、SRG）の柘植（@shotaTsuge）・岡田（@rm_rf_slant）です。 今回は、我々が組織という観点で行なっている活動について紹介したいと思います。 SRGとは はじめに私達の組織についてお話しします。 私達が所属している技術本部のSRGは、メディア管轄（AbemaTV 関連事業以外）と呼ばれる主に、Amebaサービス（アメーバブログやアメーバピグなど）や子会社が提供しているAWAやタップル誕生、技術本部が運用しているアメーバの基盤サービスや秋葉原ラボなどのインフラ周りを横断的にサポートする部署です。 SRG が普段行なっている業務としては、新規サービス立ち上げのインフラ周りのサポートや、既存サービス
Microservices時代の監視設計 - An Epicurean
前のエントリの続きです。思ってた以上に反響があったので、主語を控えることも検討しましたがこのまま行きます。前回同様、すでにMicroservicesでバリバリやっている人は読む必要ないと思います。 前回の最後にMicroservices時代になると、開発者がこれまで以上に監視に取り組んでいく必要があると言う話を書きました。多少重複するところもありますが、その辺りから話を始めます。 モノリシック世界観での監視 アプリケーション監視の浸透 Microservices時代の監視設計 開発者自身が監視する どう監視するか メトリクス設計 The Four Golden Signals USEメソッド REDメソッド USEとREDの補完関係 The Four Golden Signalsの素晴らしさ 例: ある認証コンポーネントの監視設計 まとめ モノリシック世界観での監視 Webサービスの構成が
SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告
SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告 3月13日の11時53分から15時13分（いずれも日本時間）までの3時間20分のあいだ、GmailやGoogle Drive、Google Photos、Google Storage、App EngineのBlobstore APIなどGoogleの広範囲なサービスで一部の機能が利用できなくなる、あるいは遅延が発生するなどの障害が発生しました。 その原因と対策について、Googleが「Google Cloud Status Dashboardのインシデント#19002」として報告しています。 報告では障害の原因が、ストレージ内のリソースを削減しようとしたSRE（Site Reliability Engineer）による構成変更にあったと説明。 SRE（Site Reliabili
2019年SRE考 - ゆううきブログ
この記事では、自分が数年Site Reliability Engineering (SRE)を実践しつつ、SREについて考えてきたことをまとめる。 先月開催されたMackerel Drink Up #8 Tokyoと先日開催された次世代Webカンファレンス 2019では、SREについて集中的に議論する機会に恵まれたため、脳内メモリにキャッシュされているうちに、SREに関する私的な論考をまとめておく。 (以降では、SRE本の原著にならい、技術領域名を指すときはSRE、職種名を指すときにSREsと表記する。) SREとの関わり なぜSREに関心をもったのか 2015年にメルカリさんがSREチームを発足したときに、SREsの存在を知り、SREsはシステム管理者、Webオペレーションエンジニア、インフラエンジニアといった既存の職種を置き換えていくものだと理解した。 当時、自分が注目したのは、SRE
その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜 /20180712-janog42
2018年7月12日、三重県津市で開催のJANOG42ミーティングでの発表資料です。 その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜 https://www.janog.gr.jp/meeting/janog42/program/OPE 詳細: https://www.opslab.jp/publish/20180712-janog42.html 以下の方々と議論し、多くの知見を得ることができました。(敬称略) - 長久 勝 (国立情報学研究所) - 今井 祐二 (株式会社富士通研究所) - 畠山 慎平 (エヌ・ティ・ティ・コミュニケーションズ株式会社) (運用設計ラボ合同会社 波田野裕一)
カナリアのおかげで命拾い : CRE が現場で学んだこと | Google Cloud 公式ブログ
信頼性の高いソフトウェアのリリースでは、何かおかしなことが起こったときにロールバックできることが何より重要です。そしてその方法は前回の投稿で説明しました。 ひとたびロールバックを身につけてしまえば、その次は、そもそも何かおかしなことが起こり始めていることをどうやって検知するかを知りたいと思うはずです。その方法の 1 つが、今回のテーマであるカナリア リリースです。 カナリア リリースのコンセプトは、1913 年に生理学者の John Scott Haldane 氏が、一酸化炭素を検出するためにカゴの中の鳥を炭鉱に連れて行ったことが始まりです。かよわい鳥は人間よりもこの無臭ガスに敏感で、ガス漏れが起きているとすぐに木から落ちてしまうため、それが炭鉱員にとってその場から離れるべきサインとなるのです。 ソフトウェアにおけるカナリアは通常、バイナリや設定のロールアウトなど、何らかの設定を更新してラ
1人インフラチームで、 自動化の時間を確保するために やっている（た）こと
SRE-SET Automation Night で話した内容です。 https://connpass.com/event/71497/
主要データベースの増え続けるdisk容量の対応事例
こんにちは、SRE の @masartzです。 今回は最近取り組んだ、メルカリの主要データベースの容量削減のお話をしようと思います。 TL;DR 主要データベースの容量を20%以上削減しました どういう状況だったか？ 何をしたか？ メルカリでは2017年11月現在、出品数は1日100万件を超えています。 なので、単純に日々多くのデータが増えていっています。 そのためデータベースのスケーリングは常に検討し、取り組まなければならない課題です。 今回扱ったデータベースはいくつかあるデータベースの中で商品テーブルを持つ、メルカリの主要データベースになります。 増え続けるデータに対応するための、テーブル分割を変則的な形で対応したのでその過程を紹介します。 前提：データベース分割方法 メルカリのデータベースには 会員情報や商品情報など、基本要素となるデータから、通知やお知らせメッセージなど付加的な機能
Web サービスの信頼性を守るための取り組み / jtf-2017-site-reliability-engineering
#jtf2017 ( http://2017.techfesta.jp/ ) にて『Web サービスの信頼性を守るための取り組み』というタイトルで発表しました。
書評: Site Reliability Engineering
英語だけどぜひ読んでほしい Site Reliability Engineering: How Google Runs Production Systems 参考になったのでご紹介。Googleのインフラ/Ops系技術チームの働き方や考え方を題材にした本です。GoogleのSREについては断片的に知っていたのですが、まとめて読むと違いますね。背景やストーリーがあって、理解しやすいです。 共感できるネタがどんどん繰り出されるので、一気読みしました。読み込みが浅いところもあったので、改めて読む予定。 以下、印象に残ったこと。 Site Reliability Engineering teamは、インフラ/Ops担当であるが、Unix内部やネットワークなどインフラの知見を持つソフトウェアエンジニアの集団。自分たちのオペレーションを効率的に、迅速に、確実にするために、コードを書く。 インシデント対
闇のDevOps DevOpsと業績評価 – ところてん – Medium
ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート（設置作業員、サポートセンタ）には、大量の人員が必要になってきます。 したがって、組織を研究
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最高のITエンジニアリングを支える守りと攻めの「設計技術」と「SRE」 - Speaker Deck
技術導入とその運用設計を考える 〜 過去と未来と /20180330-esd21
