プロダクションレディマイクロサービス
UberのSRE（サイト信頼性エンジニア、サイトリライアビリティエンジニア）として、マイクロサービスの本番対応向上を担当していた著者が、その取り組みから得られた知見をまとめたものです。モノリス（一枚岩）を複数のマイクロサービスに分割した後に、安定性、信頼性、スケーラビリティ、耐障害性、パフォーマンス、監視、ドキュメント、大惨事対応を備えたシステムにするために必要な原則と標準に焦点を当て、本番対応力のあるマイクロサービスを構築する手法を紹介します。本書で採用している原則と標準は、マイクロサービスだけなく多くのサービスやアプリケーションの改善にも威力を発揮します。 はじめに 1章 マイクロサービス 1.1 モノリスからマイクロサービスへ 1.2 マイクロサービスアーキテクチャ 1.3 マイクロサービスエコシステム 1.3.1 レイヤ 1：ハードウェア 1.3.2 レイヤ 2：通信 1.3.3
SREチームの長田です。 みなさま開発・運用上の定形オペレーションに伴うタスク実行をどのように管理していますか？ 今回は make をタスクランナーとして使う例を紹介します。 タスクランナーがほしい タスクランナーを使う主なモチベーションは以下の2つです。 タスクをリスト化したい タスクの実行インターフェイスを統一したい タスクがリスト化されていれば、それ自体が生きたドキュメントとして機能します。 また、タスクの実行インターフェイスが統一されていれば、 例えばタスクに前処理や後処理を追加したとしても、 開発・運用メンバーが実行するべき操作が変わることはありません。 操作変更の周知コストも下がりますし、変更に伴う操作ミスも減らすことができます。 タスクランナーに求めるもの タスクランナーの機能としては必要最低限のものがよいと考えています。 高機能なタスクランナーも魅力的ではあるのですが、タス
※本記事は2022年1月26日に公開された記事の翻訳版です。 筆者：Dylan Lau (@aidiruu), Platform DXチーム Zero Touch Production (ZTP)は、本番環境に加えられるすべての変更が、自動化、安全なプロキシ、または監査可能なBreak-glass（緊急アクセス）システムによっておこなわれるという概念です。人為的ミスに起因する本番環境での障害には、次のようなさまざまな種類があります。 構成エラー スクリプトエラー 間違った環境でのコマンド実行 ZTPはこれらのエラーによる障害発生のリスクを軽減できます。メルカリでは、ZTP環境への移行に取り組んでいます。最初のステップは、一時的な役割付与システムであるCarrierを実装することです。 この記事では、以下について説明します。 ZTPの重要性 ZTPを実装するプロセスとCarrierを始めた理
実践！マイクロサービス
2016/07/25に行われたSRE Tech Talksでの発表内容です。 http://connpass.com/event/34825/ WantedlyはDockerを本番環境で2年ほど運用してきています。ただ、Dockerにしたところでマイクロサービス化とは程遠いところにあります。この2年でようやくマイクロサービス化してきていると言える状況になってきたので、どうやったら生産性を落とさずに信頼性を担保したマイクロサービス化がきるのか、インフラチームをリードしてきた立場から現実的な視点でお話したいと思います。
※この投稿は米国時間 2019 年 10 月 4 日に Google Cloud blog に投稿されたものの抄訳です。 運用チームにエンジニアを絶えず増員しても、お客様の拡大には対処しきれません。Google のサイト信頼性エンジニアリング（SRE）の原則を適用すれば、運用上の問題にソフトウェア エンジニアリングによる解決手法を取り入れることで、うまく対処できます。本稿では、従来のネットワーク エンジニアリングの通例にとらわれず、SRE に転換することで、Google がグローバル ネットワーク運用チームを変革した方法をご紹介します。Google の本番環境ネットワーキング チームがこの問題にどのように取り組んだのかをお読みいただき、ご自分の組織に SRE の原則をどのように取り入れることができるのかを検討してみてください。 スケーリングの限界2011 年、Google の本番環境ネット
AWS障害で本当に知っておくべきことと考慮すべきこと
おはようございます、hisayukiです。 盛大なお祭りもだいぶ収束に向かってきました。 ソシャゲ大好きな人達のTwitterでの反応すごかったですね〜(；´∀｀) さて、それでは昨日のAWS障害のお祭りについて書いていきたいと思います。
本当にサービスの運用できてますか！？運用監視を学べるAWS Observability Workshopを開催しました！
本当にサービスの運用できてますか！？運用監視を学べるAWS Observability Workshopを開催しました！ 技術本部 サービスリライアビリティグループ（SRG）の柘植（@shotaTsuge）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、サイバーエージェントグループと他複数社向けに特別開催したAWS Observability Workshopの開催レポートになります。本記事を通して、運用とは何なのかを改めて考えるきっかけとなれば幸いです。 Day1 Day1では、「サービスを動かし続けるために何が必要か」というタイトルで、 運用とは何なのか Amazonでの運用例 AWS環境では、どのように運用す
SRE （Site Reliability Engineering）の実践パターンの話をします。 わたしたちが自身の経験をもとに書いたものですが、参考資料の影響を多大に受けています。参考資料がどれも厚すぎて参考にしきれていない感はあります。 これらの実践パターンはどれかが優れているというものではなく、組織やプロダクトの状況によって選択するものだと考えています。 なお次のエントリでSREを成していく道のりの話をしています。 SRE実践への道：ボトムアップの場合 SRE実践への道：トップダウンの場合 7種類のSRE実践パターン これらは順番に発生していくものではありません。また これらの実践パターンは排他的ではなく、複数を並行実施する ことがあります。 わたしたちが知る限りSREのミッション（あるいはSREに対する期待値）は両極端で、全体を俯瞰し全体最適を図る方向性の場合と、可用性・パフォーマ
Why Twitter Didn’t Go Down: From a Real Twitter SRE
Twitter supposedly lost around 80% of its work force. What ever the real number is, there are whole teams with out engineers on it now. Yet, the website goes on and the tweets keep coming. This left a lot wondering what exactly was going on with all those engineers and made it seem like it was all just bloat. I’d like to explain my little corner of Twitter (though it wasn’t so little) and some of
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog
こんにちは、エンジニアリングマネージャーの id:onk です。 Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の id:onishi、CTOの id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。 id:onkが担当する第9回のゲストは、さくらインターネット株式会社の組織内研究所であるさくらインターネット研究所の上級研究員で、SRE （Site Reliability Engineering）の研究者としても活躍する id:y_uuki さんこと、坪内佑樹さんです。 2013年にはてなに新卒でWebオペレーションエンジニアとして入社後、サーバー監視サービス「Mackerel」をはじめとするサービス開発やはてなのインフラ開発・運用にSR
![さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/5b5961cfe7e9736ef0e88bc0290b1599481d2626/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20240319%2F20240319125826.jpg)
Google Cloudの主要サービスが10時間ものあいだ障害発生。原因は分散アクセスコントロールへの大量の変更要求が引き起こしたメモリ不足
Google Cloudの主要サービスが10時間ものあいだ障害発生。原因は分散アクセスコントロールへの大量の変更要求が引き起こしたメモリ不足 Google Cloudは、米国太平洋時間の3月26日木曜日16時50分（日本時間27日金曜日 午前8時50分）頃から約10時間ほどのあいだ、Google Compute EngineやCloud Storage、Cloud SQLなどをはじめとする主要なサービスで障害を起こしていました。 受けた影響はリージョンごとに異なりますが、ほぼすべてのリージョンで何らかの影響を受けたようです。 Googleはその原因についての調査結果を発表。原因はGoogle Cloud内部でアクセスコントロールを司る部分に障害が発生したことだったと説明しました。 アイデンティティマネジメントへの大量の更新要求がキャッシュサーバの障害に クラウド内部では、APIへのアクセス
tech.mercari.com 先日からお伝えしていた通り、9/30 （土） にベルサール六本木にて第1回 Mercari Tech Conf 2017 が開催されました。 テーマに Next を掲げ、過去から現在にいたるまでに実現してきたこと、そしてこれから実現する未来について発表しました。 togetter.com それでは、簡単に各発表を振り返っていきます。 基調講演 鶴岡 達也 (Head of Engineering, Souzoh) / 柄沢 聡太郎 (VP of Engineering) / 名村 卓 (CTO) 3名による基調講演でした。 メルカリ初期の話 – 鶴岡 この頃はとにかく素早くものを作る必要があった シンプルな LAMP 構成を採用した。LAMP なのは初期のエンジニアが一番触りやすい構成、言語だから。人のスケールをさせやすいから インフラはハイエンドな1つの
SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか【Backlog Play 化プロジェクト】 | Backlogブログ
Backlog SREチームのmuziです。2018年4月から2019年7月まで、BacklogをJavaからScala / Play Frameworkに移行する大規模なリプレイスプロジェクトに参加していました。 SREとして、このリプレイスにはかなりの困難が伴いました。特にBacklogのサービス安定性は大きな問題でした。 本記事では、こうした問題に対して、SREである私がどういうアプローチを取ったのか、そしてこのプロジェクトで得られた教訓を今後チームや組織全体でどのように活かそうとしているかをご紹介します。 正直言って、泥臭い話だらけの内容です。それでも、技術的負債を抱えたプロジェクトでSREが取れるアプローチの事例の一つとして、読者の参考になれば幸いです。 はじめに ヌーラボでは2015年11月から2019年7月まで、BacklogをJavaからScala / Play Frame
ビズリーチ事業部のSREチームは、スクラムを導入して1年が経ち、タスクの可視化と脱属人化を実現しました。 導入にあたって何をしたのか、開発チームとは異なる工夫が必要だったところはどこか、導入後何が変わったのかを振り返ってみました。 ビズリーチ事業部のSREチームについて 「ビズリーチ」を担当していて、SRE(Site Reliability Engineer)としてアプリケーションエンジニアと共にプロダクトの継続的な成長のため信頼性・可用性の向上、自動化、効率化などに取り組んでいます。 なお、チームの構成は以下のようになっています。 開発者: SREチームのメンバー(5人) PO: SREチームのマネージャー スクラムマスター: 社内横断組織に所属している専任のスクラムマスター SREチームが抱えていた課題とスクラムの導入目的 まず、SREチームがスクラムを導入した背景を説明します。 PO
今年読んだ技術書籍（2019年）
今年読んだ技術書籍やレポートなどをざっくりまとめてる．Infrastructure Engineer・Platfomerとして日々の業務に直結するものから1年くらいかけてやっていきたいと思っていることなどを中心に． Kubernetes 業務ではメインにKubernetesを使っているのでKubernetesに関わる書籍は発売されれば大体目を通すようにしている． 今年発売されたので良かったのはProgramming Kubernetes．この本はCRDやOperatorによってKubernetes nativeなアプリケーションを構築することにフォーカスしている．昨年のJapanContainerDaysでのMicroservices Platform on Kubernetes at Mercariでも話したようにKubernetesを使う大きな理由の1つはその拡張性にある．Kubebu
sumirenです。 技術顧問やSREをしています。 背景 2024年現在、OpenTelemetryが盛り上がっており、ベンダへの依存度を下げてテレメトリを収集・送信することがトレンドになってきているように思います。多くの企業様で、OpenTelemetry対応のオブザーバビリティバックエンドを選定されているのではないでしょうか。 一方で、E2E自動テストツールなどもそうですが、デベロッパーツールは画面やUXの情報がパブリックな情報として出回ることが少ないように思います。オブザーバビリティバックエンドの場合、シグナル3種に関してOpenTelemetryベースでもフルに機能が活用できるのかという疑問もあります。 そうしたこともあり、オブザーバビリティバックエンドは実際にトライアルしてみないと選定しづらいです。監視など狭義のオブザーバビリティ外の機能や、OpenTelemetryの範囲外の
メルペイのマイクロサービスとCloud Native / CloudNative Days Kansai2019
CloudNative Days Kansai 2019のキーノートの資料です
インフラチームからSREへ / SRE in Mercari Developers Summit 2018
インフラチームからSREへ 〜メルカリを支える新しいインフラのあり方 Developers Summit 2018/2/16
セキュリティインシデント疑似体験調査ワークショップに参加すべき３つの理由 - Techtouch Developers Blog
はじめに こんにちは。最近はテックタッチの同僚とボルダリング同好会のようなものを作ってワイワイしてます！SRE の izzii です。 7月27日、社内の有志を集めて AWS ジャパン主催のセキュリティインシデント疑似体験 調査ワークショップに参加しました。このイベントは、AWS 環境上の典型的なセキュリティインシデントを再現したログを用いて、CTF (Capture The Flag、旗取りゲーム) 形式で AWS のセキュリティで気をつけるべきことを学べるイベントです。 テックタッチからは、izzii (SRE), roki (SRE), canalun (フロントエンド), kacchan (コーポレートセキュリティ) が参加し、その4名で構成されたチーム 「gokigen」 は約40チーム中で3位に入賞することができました！（記事のトップ画像はその時のキャプチャです ※AWS 様に
ITエンジニアから研究者へ。社会人博士として大学院にも再挑戦し、自分の「代表的プロダクト」を追求するわけ - Findy Engineer Lab
こんにちは、坪内佑樹です。Web上では、ゆううき（@yuuk1t）と呼ばれています。 僕は現在、さくらインターネット研究所で研究員を務めています。専門領域は、ITエンジニアが情報システムに対して常に変化をもたらしながら、同時に情報システムの信頼性を高めていくための技術である、Site Reliability Engineering（SRE）です。 これまで、大学院を中途退学したのち、Webサービス企業でWebオペレーションエンジニアおよびSREを5年間務めました。そして昨年（2019年）の2月から現職で研究開発に取り組んでおり、今年はさらに情報系の大学院の博士課程に社会人博士として進学します。 本記事では、昨今注目を浴びているSRE分野において「代表的プロダクト」を作ることに憧れ、それを目標の軸に据えて、なぜエンジニアから研究者になる「選択」をしたのかをご紹介します。 大学で研究するより、
See time spent per project, file, or feature Compare time in meetings vs coding Identify bottlenecks in your codebase Compete with leaderboards and goals
SRE NEXT Logo はじめに こんにちは！SRE NEXT 2022実行委員会委員長のnari です。 先日、SRE NEXT公式Twitter アカウントにてSRE NEXT 2022の5/14,15の日程でのオンライン開催が発表され、オフィシャルサイトも公開されました！ この投稿では、なぜ我々はSRE NEXT 2022を開催するのか・どんなカンファレンスにしたいかを書いていきます。*1 2022/2/7追記: スポンサー募集開始しました SRE NEXT 2022 スポンサー応募フォーム 2022/2/7追記: CFP Openしました SRE NEXT 2022 の CFP についてのご案内 - SRE NEXT Staff Blog SRE NEXTとは 信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスであり、同じくコミュニティベースのSRE勉強
この記事は、トラストバンク Advent Calendar 2021の20日目です トラストバンクでSREをしている@Tocyuki（としゆき）です！ トラストバンクへ入社してちょうど1年となるので本記事ではこの1年SREとしてやってきたことを書きたいと思います！ 一人目のSREとして 私は去年の12月に一人目のSREとしてトラストバンクへ入社しました。 入社の経緯やキャリア等については弊社Wantedlyのストーリーにインタービュー記事があるので是非見てみて下さいー！ https://www.wantedly.com/companies/trustbank/post_articles/305115 トラストバンクの運営しているサービスにふるさとチョイスというふるさと納税サイトがあります。 ふるさと納税サイトの先駆けであり、入社前から知っているサイトでもありました。 入社前までは社内にイン
75億ドキュメント以上のデータを保持するMongoDBを、Amazon EC2からMongoDB Atlasへ約3ヶ月で移設した方法 | CyberAgent Developers Blog
75億ドキュメント以上のデータを保持するMongoDBを、Amazon EC2からMongoDB Atlasへ約3ヶ月で移設した方法 はじめに タップル SREの赤野、CAM SREの庭木です。 タップルは2021年3月頃にMongoDB on Amazon EC2(以下EC2 MongoDB)からMongoDB Atlas(以下Atlas)への移設を行いました。 今回はこの移設での取り組みについて紹介します。 Atlasへ移設することになった経緯・目的 タップルでは定期的にキャパシティプランニングを目的とした負荷試験を実施しており、今後のDAU増加のシミュレーションに対してシステムのキャパシティが確保できるかを定期的に確認しています。 タップルSREのキャパシティプランニングの取り組みについては、以前発表させていただいた資料があるのでこちらにも目を通していただけると幸いです。 2020年
SRE四大行 | 外道父の匠
元々なんでも屋ってたけど、我が部署名もSREになったし、インフラエンジニアって書くと『IT』警察が寄ってくるからSREでいきましょう。短いのはイィ。 SREがやることは書籍『O’Reilly Japan – サイトリライアビリティワークブック』がほぼ語っていますが、もうちょっと噛み砕いて自分的にはこの四大行を軸に活動すれば、いっぱしのSREになれんじゃねっていう戯れであります。 SREのお仕事を大雑把に表現すると、サービス開発者が作成したアプリケーションを、動かす環境を用意し、安全・効率的に動かし続けることだと思っています。 IT業界の事情変化につれて、SREの重要性は高まる傾向にあり、それに伴いSREとして活動を希望する人材も増えたような、そうでもないような。気がするけど、SREとして食ってく気ならこれら四大行が基本であり奥義になるよって話です。 『構築』 アプリケーションを動かすための
SRE-SET Automation Night で話した内容です。 https://connpass.com/event/71497/
エムスリーエンジニアリンググループ AI・機械学習チームでソフトウェアエンジニアをしている中村(@po3rin) です。最近、AI・機械学習チーム配下の検索基盤チームでElasticsearchのAnalyzerをKuromojiからSudachiに移行しました。今回はSudachi移行の背景と、Sudachiの概要、実際に移行するにあたってのプロセスや注意事項をお話しします。 対象読者 なぜSudahchiに移行したのか 検索基盤チームが抱えていた検索の課題 Sudachiとは Sudachiへの移行戦略と実践 今使っているKuromojiユーザー辞書をSudachiユーザー辞書に移行する 今使っているシノニム辞書からSudachi正規化機能でまかなえるものを削除する 平仮名/カタカナの正規化辞書を作る 移行時のSudachi切り替え戦略 移行後の影響の事前確認 Sudachi移行時のハ
踏み台サーバー、SSMセッションマネージャー、EC2 Instance Connect Endpoint サービスを使用したEC2インスタンスへの接続方法と特徴を比較してみた - NRIネットコムBlog
はじめに 踏み台サーバー経由で接続する方法 ①セキュリティグループを作成する ②パブリックサブネットに踏み台サーバを作成する ③プライベートサブネットにEC2インスタンスを作成する ④踏み台サーバーにプライベートサブネットに配置されたEC2インスタンスのキーペアをコピーする ⑤踏み台サーバーにアクセスする ⑥踏み台サーバーからプライベートサブネットにあるEC2インスタンスにアクセスする SSMセッションマネージャー経由で接続する方法 VPCエンドポイントを使用した方法 ①セキュリティグループとIAMロールを作成する ②プライベートサブネットにEC2インスタンスを作成する ③VPCエンドポイントを作成する ④SSMセッションマネージャー経由でEC2インスタンスに接続する NATゲートウェイを使用した方法 ①IAMロールを作成する ②プライベートサブネットにEC2インスタンスを作成する ③NA
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2017年6月） 出典は脚注などを用いて記述と関連付けてください。（2017年6月） 脚注による出典や参考文献の参照が不十分です。脚注を追加してください。（2017年6月） 出典検索?: "インシデント・コマンド・システム" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL インシデント・コマンド・システム（現場指揮システム、Incident Command System、ICS）は、米国で開発された災害現場・事件現場などにおける標準化された管理システムのこと。インシデント・マネジメント・システム (Incident Management Sys
はじめに こんにちは、計測プラットフォーム開発本部SREブロックの近藤です。普段はZOZOMATやZOZOGLASS、ZOZOFITなどの計測技術に関わるシステムの開発、運用に携わっています。 計測プラットフォーム開発本部では、複数のプロダクトを開発運用していますが、リリース作業はプロダクト単位で行っています。プロダクトによってローンチから数年経過し安定傾向のものもあれば、ローンチしたばかりで機能開発が盛んなものもある状態です。 複数のプロダクトを管理する上では当然の状況ですが、プロダクト単位でリリース作業手順が異なり、手順そのものにも課題がある状態でした。 本記事では、リリース作業で課題となっていた部分の紹介と、それぞれの課題に対する対応策についてご紹介します。 目次 はじめに 目次 現状 課題と対応方針 リリース作業の自動化 リリース作業の自動化をする上での必須条件の確認 自動化が必要
はじめに 自分は Martin Kleppmann が言うデータ指向アプリケーションやそれを実現する周辺の技術領域が好きで、業務としてそのような領域のエンジニアリングを引き続きやっていけたらなと思っています。 世の中には関連する職種の求人が多々ありますが、同じ名前のロールでも職務内容がコンテキストによって異なることが多かったりします。 ここではそれぞれの職種の違いについて自分の観点からまとめます。 1. データエンジニア 求人を眺めていると、データエンジニアは企業によって割と役割がぶれるので分けて説明します。 1-1. 小さめの事業会社のデータエンジニア まずは、小さめの事業会社のデータ分析基盤の構築・運用をするロールです。 ここでは ETL 処理の実装・運用のほかに、各種ツールを使ったデータ基盤の構築・運用知識やクラウド上のアプリケーション構築の知識などが求められることが多いです。 さら
ZOZOTOWNのProduction Readiness Checklistと信頼性向上の取り組み / Improvement the reliability of ZOZOTOWN with Production Readiness Checklist
ZOZOTOWNのProduction Readiness Checklistと信頼性向上の取り組み / Improvement the reliability of ZOZOTOWN with Production Readiness Checklist
Go 製ソフトウェアでメモリ使用量の多い関数を特定する - Cybozu Inside Out | サイボウズエンジニアのブログ
みなさんこんにちは．SRE チームの内田（@uchan_nos）です． この記事では Go 製ソフトウェアのどの関数がどれだけメモリを消費しているかを調べる方法を説明します． Go 製ソフトウェアのヒープメモリの消費量を調べる方法はたくさん解説されているものの，スタックメモリの消費量について調べる方法を説明したサイトを見つけることはできませんでした． この記事では主にスタックメモリの消費量を調べる方法を説明します． 背景 SRE では Go 言語で自社データセンター向けのツール群をたくさん作っています． その中のソフトウェアの 1 つが，本番運用中に予想外にたくさんのメモリを使用してしまうという問題がありました． どの関数が原因なのかを突き止めるために，関数単位でメモリ使用量を調べる必要があります． ソフトウェアが使っているメモリ量の概況は，Linux であれば top コマンドで調べるこ
近年、何かと話題に上がるSRE（Site Reliability Engineering）。しかし、「自分たちのチーム・組織に関係する話なのかよく分からない」「具体的に何をやればいいの？」といった感想を持つ方は多いのではないでしょうか。本連載では、そういった方に向けて、自社でSREチームの立ち上げを行った筆者が、SREの考え方 をご紹介します。また、連載の後半では、SREをいち早く取り入れた企業に導入背景などもインタビュー形式でお伝えする予定です。第一回となる本記事では、「SREって何？」「SREをやりたいが、どこからはじめればよいのか分からない」 方に向けて、SREの概観をご紹介します。 はじめに はじめまして。株式会社スタディスト SREチームの@katsuhisa__です。 スタディストでは、システム運用に関わる全般的な業務にはじまり、モニタリングやログ収集基盤の整備などを担当してい
【開催報告】プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜 | Amazon Web Services
Amazon Web Services ブログ 【開催報告】プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜 みなさんこんにちは！アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの後藤です。 2024 年 2 月 29 日に AWS オンラインセミナー「プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜」を開催しました。 本イベントは、プラットフォームエンジニアリングの基本的な概要と現状について解説した上で、SRE や DevOps との関連性、どんな課題をどう解決するのか、実装するとなれば、AWS でどう実現するのかといった点についてご紹介させていただきました。400 名を超える多くの方々にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました！ アジェンダ AWS メンバーから、プラット
株式会社MIXIで『家族アルバム みてね』（以下みてね）のSREグループに所属している本間です。 みてねは現在、1,500万人を超えるユーザに175の国と地域でサービスを提供しています(2022年8月現在)。そこで、より高い信頼性と可用性を担保するためにみてねのSREグループではオンコールエンジニア制度を設けています。 今回はこの「みてねのSREグループにおけるオンコールエンジニア制度の取り組み」についてご紹介させて頂きます。 オンコールの定義 まず、どのような条件でアラートを設定しオンコールを実施するかの定義について簡単に触れておきます。 現在はさまざまなソースから多種多様な情報を収集することができます。 たとえば、みてねではKubernetes（Amazon EKS）を採用しています。Kubernetesだけでも非常に多くのメトリクスが収集できますが、それだけではなくアプリケーション
こんにちは、SPEEDAのSREチームでエンジニアをしている阿南です。SPEEDAのSREチームでは、昨年末kubernetesについて理解を深めるために合宿を行いました。やり方はA〜Cの３チームに分けて、それぞれのチームでkubernetesに関することを調査、構築するという形式で、今回はAチームが実際にやってみた内容についてブログを書きたいと思います。（それぞれのチームでかなりボリュームがあるので、複数回に渡って連載的な形でお届けしたいと思います。） Aチームでは、kubernetesを本番環境に投入するにあたり、ログ収集周りをあまり調査できてないなと感じ、GCP上に環境を作ってみることにしました。 構築する環境 構築手順 クラスター構築 wordpress + MySQL構築 Fluentdイメージの作成 ConfigMap設定 DaemonSet設定 まとめ お知らせ 構築する環境
ざっくり理解するSRE - Qiita
昨今では自社のプロダクトやシステムのエンゲージメント向上のために、「DevOps」や「アジャイル」といったキーワードのもと、大小さまざまな企業がシステムやアプリの開発手法の改善を試みています。その中において、最近だと「SRE」というキーワードを聞く頻度も多くなってきたかと思います。 しかしアジャイルやCICDなどと比べ、SREについては「言葉は知ってるけど具体的になんなのかはよくわからない」という方もいるのではないでしょうか？ここではそんな方々向けに、SREの最初の一歩となる概要について、独自の解釈を交えつつまとめていきます。 ここで話すこと SREって何？ なぜSREが必要？ SREってどんなことするの？ ここで話さないこと SREの技術の具体的なところ（k8sやAPMの導入手順、設定方法など） プラクティスの実践例・具体例（アーキテクチャ、各種設定値、モニタリング指標など） TL;DR
新サービス Aurora Serverless v2 の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering
2022.06.16 技術記事 新サービス Aurora Serverless v2 の検証とその評価 [DeNA インフラ SRE] by Keijun Kumagai #infrastructure #aurora #aws #database #technical-verification #game-infrastructure #infra-quality こんにちは！IT基盤部の k-jun です。IT基盤部にて大規模ゲームのインフラを見ているインフラエンジニアです。この記事では、2022/04/21 に GA となった AWS の新サービス Aurora Serverless v2 に対して行った技術検証とその調査結果をご紹介させて頂きます。 Aurora Serverless v2 とは Aurora Serverless v2 は Amazon Aurora のオンデマン
![新サービス Aurora Serverless v2 の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/edc2033bd2be270f3538bbd3e3b9bd2d546575d4/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2022%2F06%2Faurora-serverless-v2%2Fcover.png)
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
タスクランナーとしてのmakeを使う際の工夫と注意点 - KAYAC engineers' blog
Zero Touch Productionへの移行 | メルカリエンジニアリング
ごく普通のエンジニアリング運用チームを強力な SRE チームに変える | Google Cloud 公式ブログ
SRE実践の形：7種類の SRE 実践パターン - 株式会社X-Tech5
クリティカルユーザージャーニーを利用した SLI/SLO の改善 / #mackerelio
第1回 Mercari Tech Conf を開催しました | メルカリエンジニアリング
SREチームがスクラムを導入し1年でタスクの可視化と脱属人化を実現した話
【OpenTelemetry】オブザーバビリティバックエンド8種食べ比べ
WakaTime - Dashboards for developers
SRE NEXT 2022を開催します - SRE NEXT Staff Blog
ふるさとチョイスのSREとしてこの1年やってきたこと - Qiita
1人インフラチームで、 自動化の時間を確保するために やっている（た）こと
検索基盤チームのElasticsearch×Sudachi移行戦略と実践 - エムスリーテックブログ
インシデント・コマンド・システム - Wikipedia
GitHub Flow with GitOpsの導入 - ZOZO TECH BLOG
データ系エンジニアの職種の違い - satoshihirose.log
SREって何？ これまでのシステム運用やDevOpsとは何が違うの？
『家族アルバム みてね』を支えるオンコールエンジニア制度 | gihyo.jp
【k8s合宿】 Kubernetesのログ分析環境を作る - Uzabase for Engineers