SRE大集合！みんなで学ぶ、信頼性を高めるための取り組みLT大会の登壇資料です。 概要 つい先日SLI/SLOの設計が終わりSLOの運用をスタートしましたがそれまでの道のりは楽ではありません…
SRE大集合！みんなで学ぶ、信頼性を高めるための取り組みLT大会の登壇資料です。 概要 つい先日SLI/SLOの設計が終わりSLOの運用をスタートしましたがそれまでの道のりは楽ではありません…
Istioは、サービスメッシュを実現する新たな仕組みとして試験的に開発していた「Ambient Service Mesh」をメインブランチに統合し、正式な機能として組み込んで行く方針であることを発表しました。 現在のIstioは、各サービス（≒KubenetesのPod）ごとにプロキシを配置し、サービス間のネットワークをプロキシ経由で構成することによってサービスメッシュを構築しています。これによりサービス間の通信のトラフィックコントロール、暗号化、可観測性（オブザーバビリティ）などの機能が実現されるわけです。 この仕組みは、サービスの隣にプロキシを配置することから、「サイドカー」パターンなどと呼ばれています。 しかしPodごとにサイドカーをデプロイする必要があるため、これにかかる手間やリソースの消費が課題でした。 eBPFを用いたサイドカーフリーなCiliumへ注目が集まる そうした中で最
マイクロソフトが「FinOps Foundation」に加盟を発表。クラウドのコストの透明化と最適化を推進 FinOpsとは昨年頃から注目され始めた言葉です。 DevOpsが、Ops（運用）からフィードバックを得て開発（Dev）を改善していくというサイクルを繰り返すのと同じように、FinOpsでは運用からフィードバックを得てクラウドのコスト（Fin：Financial）を最適化していく、という意味が込められています。 FinOps Foundationにおいても、クラウドで発生する費用の透明性を高め、可視化し、それを最適化し、改善を続けていくことを「FinOps」としています。 オンプレミスのシステムではハードウェアもソフトウェアも、基本的にはあらかじめ見積もられた通りの費用が発生することが購入時点で分かっています。 しかしクラウドは従量課金制であるため、費用に柔軟性がある一方で、コンピュ
Amazon Route 53 Application Recovery Controller zonal shift 試してみた #reinvent #jawsug #opsjaws | DevelopersIO
コンバンハ、千葉（幸）です。 先日行われた Ops JAWS Meetup#22 re:Invent 2022 recap & LT大会 にて、Amazon Route 53 Application Recovery Controller zonal shift 試してみたというタイトルで発表しました。 当日の発表資料の共有・およびその補足を行います。 おことわり Amazon Route 53 Application Recovery Controller zonal shift は現時点でプレビューです 正式リリース時には仕様や公式ドキュメントの記述が変わる可能性がありますのでご留意ください わたしの発表内容は2022/12/7時点の情報に基づいています 公式ドキュメントはこちら。 Zonal shift in Amazon Route 53 Application Recovery
みてね×gihyo.jpスペシャル 『家族アルバム みてね』に学ぶ、AWSのReserved InstancesとSavings Plansの勘所 『家族アルバム みてね』（以下、みてね）ではサービスの拡大に合わせてAWSのコスト削減のために、2018年から5年間にわたってReserved Instances（以下、RI）とSavings Plans（以下、SPs）の活用をしています。 現在に至るまでの間、サービスやインフラの成長に合わせそれらの使い方を試行錯誤してきましたが、振り返ってみるとどのタイミングでも注意すべきポイントは共通していることがわかりました。 そこで今回の記事では、みてねでのRI/SPsの活用の歴史を振り返りながら、それぞれを購入する際に注意すべきポイントについて共有いたします。 RIとSPsとは 振り返りの前にまずは、RIとSPsの概要について紹介します。 RIと
【開催報告＆資料公開】運用を楽にしよう！AWS Systems Manager 事例祭り | Amazon Web Services
Amazon Web Services ブログ 【開催報告＆資料公開】運用を楽にしよう！AWS Systems Manager 事例祭り こんにちは。ソリューションアーキテクトの石橋です。 2022年11月4日に「運用を楽にしよう！AWS Systems Manager 事例祭り」と題したイベントを開催しました。クラウドを活用したシステム運用の中核を担う AWS Systems Manager の日本初のお客様事例紹介イベントです。 対面とウェビナー配信のハイブリッド形式でお届けしましたが、多くの方にご参加いただきました。登壇者の PayPay 株式会社様、株式会社 三越伊勢丹システム・ソリューションズ様からは AWS Systems Manager を活用した運用効率化に関する様々なエピソードをお話しいただきました。ご参加いただいたみなさまには改めてお礼申し上げます。本エントリではその内
序文 こんにちは。MonotaROの伊藤です。 弊社では障害対応訓練の実施手法の一つであるWheel of Misfortune(略称:WoM)を実践しています。WoMの導入で、障害対応体制の強化を行うことができましたので、実施までの経緯や得られた学びなどを中心に紹介したいと思います 序文 運用担当者の負荷が高まり続ける問題 運用担当者=社歴が長いベテランエンジニア 運用のスケールアウト 障害対応訓練をやってみよう 訓練環境の準備の問題 訓練シナリオの問題 外部からの助け Wheel of Misfortuneとは 実施時の様子 シナリオ開始時の様子 モニタリング画面の表示 WoMとDiRT(Disaster in Recovery Training) 障害対応訓練をやってみた結果 準備時点で感じたメリット 手順書の不備を発見できたこと 障害が起こりかねない場所を考えるきっかけになったこと
Amazon Web Services（AWS）は、機械学習の実行環境を提供する新サービス「SageMaker Studio Lab」を無料で提供すると、開催中のイベント「AWS re:Invent 2021」で発表しました。 SageMaker Studio Labは、機械学習の実行環境として広く使われているオープンソースのJupyterLab IDEをベースにした新サービスです。PythonやR言語などに対応しており、ターミナル機能やGitとの連携機能などを備えています。 AWSには、すでに「SageMaker Studio」がサービスとして存在していますが、今回発表された「SageMaker Studio Lab」は機械学習の教育を目的とし、機能の一部をサブセットとして取り出したものといえます。 インストールやセットアップなどは不要で、Webブラウザからすぐに利用可能な環境が立ち上が
こんにちは、メルペイでSREとして従事している @myoshida です。この記事は Merpay Tech Openness Month 2021 の8日目の記事です。 SREチームはお客さまへよりよいサービス利用体験を提供するため、日々様々な改善活動に取り組んでいます。その活動の一環としてPlaybookの概念を導入し、運用者の運用負担を減らす取り組みを始めました。今回はそのことについて説明してみたいと思います。 概要 メルペイではアプリケーションエンジニアとSREの双方がオンコール制度のもと運用に携わっています。 運用の悩みは様々ですが、そのうちの1つに手順書の取り扱いがあります。 どこに置くべきか、更新はされているのか、何を書けばいいのか、どの場面でどの手順書を利用すればよいのかというような悩みはどこの現場でも少なからず存在すると思います。 そこで、Playbookと呼ばれる体系的
最初に注意: この文章は「はじめに」「総論」が長いです🙃 追記＠2021/08/11 17:46想像よりはるかに反響をいただいたので、せっかくだからと要点をMarkdownにしてGitHubに置いてみました。何かにご利用ください。 はじめに・「仕事のコード」、つまり、業務などで作ったコードが、なるべく負債にならず、なるべく俗人化しないようにするために留意すると良さそうなことを自分の経験などから列挙したものです。 ・ちなみに、「対象読者」に書いてありますが、そもそものモチベーションが「非エンジニアがノーコード系のサービスで作ったシステムが最近増えつつあるような...」というところでした。こういうのどう取り扱うといいんですかねとなった時、まずは運用できる形にしてもらいたい、という狙いがあります。結果的に、ジュニアなエンジニアが良いシステムを残す上でも使える知識かなと思います。 ・個別の項目に
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
パフォーマンスの良いGASの書き方 Best Practice啓介 大橋16.1K views•70 slides
こんにちは、技術開発室の滝澤です。 今回はクラウドと可用性についてのポエムを書いてみたいと思います。 まとめを最初に書くと次のようになります。 原則としては、ゾーン冗長構成にすることで可用性は向上する。 クラウド事業者側のソフトウェアのバグやヒューマンエラーなどが原因の障害ではゾーン冗長構成でも回避できない場合がある。 マルチリージョン構成やマルチクラウド構成は本当にそのレベルの可用性が必要かどうかを検討する。 可用性（アベイラビリティ） まず最初に可用性についての復習をしてみましょう。 可用性は英語のavalability（アベイラビリティ）を日本語に訳した言葉で、簡潔に述べると「利用したいときに利用できる能力」という意味です。日本語としては稼働率と呼ばれることもあります。 例えば、あるサービスのウェブサイトが、障害が起きない、あるいは障害が起きてもすぐに復旧していつでも利用できる状態に
30; }, handleResize() { if (window.innerWidth >= 1024) { this.mobileOpen = false; this.dropdownOpen = 'none'; } }, checkAnnouncementBanner() { const announcementBanner = document.querySelector('.announcement-banner') || document.querySelector('.announcement-banner--large'); if (announcementBanner) { this.hasAnnouncementBanner = true; } else { this.hasAnnouncementBanner = false; } } }" x-init="chec
【日時】 2025年9月5日（金）9:50-17:00（終了後懇親会を開催） ※9:30開場 【場所】 docomo R&D OPEN LAB ODAIBA 東京都港区台場2-3-2 台場フロンティアビル 12F 【内容】 基調講演、スポンサー講演、パネルディスカッション、一般講演、OpsMeetup、アワード表彰、展示ブース、懇親会など
latestタグや書き換えるためのタグ（develop, stagingなど）を使って、本番で運用するのはやめましょう。 コンテナイメージのキャッシュ状況やリリースフローによっては予期しない形で 予期しないバージョンが本番で起動する可能性があります。 本記事では、どのプラットフォームやツールで発生したかについては記載しません。 本題はそこではないのと、そもそも運用が間違っているので 記述しても余計な枝葉になるからです。 この記事ではどういうことが起きたか、について書きます。 どういうことが起きたか サービスで、dockerイメージのlatestタグを使って本番運用していた。 全コンテナをgraceful restartしたようだ。（つもりだったが・・・） 別の作業中、管理画面の表示がおかしくなっているという話が出てきた。 そこで調べてもらったところ、なぜかリリースしたはずの機能が正常に機能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
