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年
今回のテーマは「分析基盤をうまく組織に浸透させる方法」です。 「分析基盤を浸透させていく上で、分析基盤を担う組織(分析基盤組織)がどのように形を変えていったか」という内容です。組織設計の参考になれば幸いです。
ここ数年、アジリティとセキュリティ(あるいはガバナンス)の両立について考える機会が多い。伝統的で規模の大きい企業にありがちな傾向として、セキュリティやガバナンスを確保するためにはシステムの開発/運用が鈍重、高コスト、不自由になったとしても已む無しとする思想がしばしば見受けられる。結果として例えば簡単な仮想サーバ１つを用意するだけでも数ヶ月の納期と膨大な工数を要するとか、世の中で当たり前に活用されている技術やプロセスが許可されない/導入に非現実的な手続きを要求されるといった状況が生まれる。 確かにシステムの安全性を適切にコントロールすることは重要である一方で、論理的に考えれば「セキュリティのためのビジネス」ではなく「ビジネスのためのセキュリティ」なのだから、セキュリティを確保するためにビジネスの成功が妨げられてしまっては本末転倒に思える。しかし実際には「セキュリティのためなので仕方がない」と
Kaggleの学習から投稿までをAWS, GitHub Actionsを使って自動化する - kanayamaのブログ
金山（@tkanayama_）です。先日終了したKaggleの"M5 Forecasting"というコンペに参加した際、クラウドやCI/CDの勉強も兼ねて、AWS, GitHub Actionsを使って遊んでみました。 免責 N番煎じだったらすみません。一応、同じことをやっているネット記事は見つかりませんでした。 私はクラウドなど勉強中の身分ですので、もっといいやり方がある or 説明が間違っている、などありましたら教えてください。 私がこのシステムを使って参加したコンペの順位は5,558チーム中1,000,000,000位だったので、Kaggleで勝てるかどうかは別問題のようです :pien: この記事のゴール 下記のようなシステムを構築することをゴールとします。 ユーザーがやることは2つ（図中でユーザーから伸びている黄色矢印）で、 実装したコードをgit pushし、 AWSコンソール
GitHub - openstatusHQ/openstatus: 🏓 The open-source website & API monitoring platform 🏓
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
6年ほど無停止のサービスを運用してきた私の経験からすると、メンテナンスウィンドウ、つまり計画的メンテナンスに対するアラート発砲を抑制する機能は、使わないほうがうまくいく。仕事の中でも度々メンテナンスウィンドウの話題が出てきたので、個人の見解としてまとめてみたい。 計画的メンテナンスの手順 対外的に無停止だとしても、内部的には停止を伴うメンテナンスをすることがある。たとえば、MySQLを止めることはたまにある。まずは、どのようにメンテナンスを進めていくのかを整理しよう。 内部的な停止を伴うメンテナンスの際は作業に必要な時間とともに、アラートが起こる範囲を予測し、予告しておく。予告の範囲を決めるのは単純で、アラートが届くだろうチャンネルにお知らせしておけばいい。以前のチームではメールとSlackチャンネルを使っていたので、そこに書いていた。準備はこれでいい。 メンテナンス作業が始まる（たとえば
「MLOpsとはなにか？」という質問に対し、「データサイエンティストが、システム開発において、やらないことすべて」と定義した上で、MLOpsの説明、海外事例、「JapanTaxi」アプリでの事例を説明しますRead less
モバイルゲームの運営を譲り受け「長命化」させるマイネット。彼らはどのようにサービスを移管しているのか？インフラ担当会社ビヨンドと共に内情を明かす - AUTOMATON
サービス型のゲームには、いつか終わりが訪れる。しかし、その寿命を伸ばすことは可能。株式会社マイネットは、数々のスマホゲームを他社から譲り受け、長期運営を目指す「ゲームサービス事業」を柱としている。さまざまなスマホゲームの運営が続けられており、現状の運営タイトル数はなんと36本（※2020年9月時点）に及ぶ。中には『黒騎士と白の魔王』『ウチの姫さまがいちばんカワイイ』といった有名タイトルの名も。しかし、実際にサービス移管をするとなると、運営だけでなくサーバーやプログラムなどのシステム部分も譲渡されることになる。そうした移管は実際どのようにおこなわれるのだろうか。 マイネットの運営移管の影には、そのサーバーの運用や保守を担当する株式会社ビヨンドの貢献があるようだ。ビヨンドは、サーバーの保守運用やシステム開発を業務とする会社だ。本稿ではマイネットの膨大なゲームの同時運営を可能にしているインフラ技
インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『運用改善の教科書』の著者である近藤氏が登壇。続いて、ITIL4の登場に伴う運用の考え方の変化と、昨今の運用に求められていることを紹介します。前回はこちらから。 2019年頃に起きた運用の変化 近藤誠司氏（以下、近藤）：みなさん運用をやっている方が多いということで、ご存知のITIL（Information Technology Infrastructure Library）のv3、シラバス2011をベースにしたものを貼っています。いろいろとプロセスや機能などがあって、分類がありました。 シラバス2011、ITIL v3の時点では、基本的にはサービスストラテジが戦略を練る、サービスデザインは設計するというところです。トランジションは、設計したものを作って移行する
第6回さくらインターネット研究会
デブサミ2020で「礼節から育てるチームの健康と信頼性」という話をしました #devsumi #devsumic | DevelopersIO
事業開発部の塩谷 (@kwappa) です。 2020年2月13, 14日、目黒雅叙園でDevelopers Summit 2020（通称「デブサミ」）が開催されています。その初日である2/13、 13-C-6 という枠をいただいて「礼節から育てるチームの健康と信頼性」という話をしました。 スライド セッション 昨年10月から継続してしゃべっている、チーム・心理的安全性・礼節についての総集編を目指してつくりました。過去のセッションから大きく変えてはいませんが、登壇を重ねるたびに自分でも理解が深まったように思います。 公式サイトの事前予約では「満席」の表示があり、実際のセッションもちらほら立ち見の方が出るぐらいの入場がありました。公募に通ったのも不思議なぐらいのふわっとしたタイトルでしたが、たくさんの方に聞いていてだけてとても光栄ですし、話し甲斐もありました。 聴いてくださったかたのツイート
GitOpsとは、分散バージョン管理システムであるGitを使用して、全てのアプリケーションとインフラストラクチャの望ましい状態を宣言的に記述し、管理する手法で、継続的デリバリーを実現する一つのモデルです。本連載では、GitOpsを活用した継続的デリバリーやプログレッシブデリバリーについて紹介します。第1回では、GitOpsの概要やメリット、GitOpsを実現するソリューションを紹介します。 はじめに 本連載はソフトウェアデリバリーにおける継続的デリバリー・プログレッシブデリバリーについての連載で、以下の3つの記事で構成されています。 第1回となる本記事では、継続デリバリーについての概要、話題となっているGitOpsは何か、どんなメリットがあるのか、現在のGitOpsソリューションについて紹介します。 第2回では、プログレッシブデリバリーの解説と各ソリューションの紹介・比較について説明します
ご挨拶 初めまして @moriya-snj です。 この記事は「本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita」の15日目の記事です。 みなさん盛大にやらかしている様で安心しております。 今回は私が社会人3ヶ月目でやらかした重大事故の記録を包み隠さず暴露するとともに当時フォローしてくださった先輩や上司お陰でなんとかこの業界で生き抜くこと出来ていることの感謝をお伝えすべく、キーボードに手を伸ばしております。 何をしでかしたか 顧客AがIP電話を導入するため、新たにVoIP用ネットワークを構築することとなった。 機器の設置等は別部署が行うため、設置依頼を出し、完了の報告をもらったため、ネットワーク機器のコンフィグなどを流し込み疎通確認などを行うこととなった。 疎通確認が完了し、お次はVRRPの切替確認を行おうとしたが、ここで誤って稼働中の顧客Bのネットワ
Transcript 1 ϝϧΧϦʹ͓͚ΔੳڥඋͷऔΓΈ גࣜձࣾϝϧΧϦ / JP Data Analyst ӬҪ৳ 2 Introduction 3 ! ӬҪ ৳ ! גࣜձࣾϝϧΧϦ / JP ! Data Analyst ◦ ੳڥͷඋͳͲΛ୲ ࣗݾհ 4 ! ݱঢ় ◦ ͳͥվળʹऔΓΉͷ͔? ! ͋Γ͍ͨ࢟ ◦ վળͷαΠΫϧΛճ͍ͨ͠ɻ ! औΓΈ ◦ ϨΨγʔͳσʔληοτΛഇࢭ͢Δɻ ◦ ͦͷͨΊʹɺۀͱKPIͱج൫ΛηοτͰߟ͑Δɻ ΞδΣϯμ : ϝϧΧϦʹ͓͚Δੳڥͷඋͷࣄྫ 5 ݱঢ় | ͳͥվળʹऔΓΉͷ͔? 6 ! ج൫ ◦ BigQuery + Looker ! ن ◦ ΫΤϦ࣮ߦϢʔβʔ 700ਓҎ্/݄ ◦ ࢀর͞Ε͍ͯΔςʔϒϧ 100Ҏ্/݄ ◦ Analyst, PdM, ML, CS, ͳͲ ϝϧΧϦʹ͓͚
サイト信頼性エンジニアリングのドキュメント
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー - TC3株式会社｜GIG INNOVATED.
State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー はじめに State of DevOps ReportはDevOpsの成熟度についてアンケート形式で調査しているレポート資料です。毎年アップデートされているので、直近の動向などを理解し、かつ課題解決の活路を見出すのに良いレポートです。2021版が先日リリースされていました(もとのレポートはこちら)。 デジタルトランスフォーメーションの文脈の中で、ソフトウェア開発がますます増えてきていますが、単に一発作っておしまいではなく、継続的に進化させることが求められます。継続的にサービスを進化させていくことがビジネス力の根源となるということをアンケート調査から証明したのが、このレポートで、調査内容については、『LeanとDevOpsの科学』をご一読いただく
KaggleOpsを考える ~ MLflow + Colaboratory + Kaggle Notebook ~ - GMOインターネットグループ グループ研究開発本部
2020.10.05 KaggleOpsを考える ~ MLflow + Colaboratory + Kaggle Notebook ~ こんにちは。次世代システム研究室のY. O.です。 筆者はデータ分析のスキルアップのためにkaggleというデータ分析プラットフォームを活用しています。kaggleを始めてから約2年間を経て、スキルアップの枠を超え、趣味・生活の一部・etc.になってきてしまっているのも認めざるを得ません。。。 今回は、先日kaggleの自然言語処理コンペ（Tweet Sentiment Extraction）で2位になった結果を題材に、振り返りの意味を込めて”こうしておけば良かった”という点をMLOpsの観点でまとめていきたいと思います。 ここで、kaggleを取り巻くMLOpsの構成をKaggleOpsと勝手に呼ぶこととし、少なくとも筆者は今後のコンペでも以下にまとめ
このブログはこんな方におすすめ 緊急対応の初動を早めたい リモートワーク中心になり、緊急対応中の作業分担や進捗確認が難しい Google Apps Script で緊急対応時の Slack 操作を自動化してみた の Python 版がほしい 2021年6月11日に以下のセッションに登壇しました。本ブログでは登壇中に紹介するとお伝えした関数をご紹介します。また背景についても改めて少し記載しています。 業界特化事例紹介セッション SIer編 | Slack はじめに クラスメソッドでは Slack API を活用することで、いくつかある緊急対応の初動が約30分早くなりました。 では、どのように活用して初動対応を迅速化したのでしょうか。 本ブログでは、クラスメソッドの緊急対応の一つである、AWS 不正利用対応を例に紹介します。 AWS 不正利用とは、AWS アクセスキーの漏洩などが原因で発生しま
[レポート] オペレーション、監視(Monitoring)、可観測性(Observability)… AmazonのCTOはAWS re:Invent 2020のキーノートでどう語ったか？ キーワードを拾ってみた #reinvent | DevelopersIO
昨年12/18（日本時間では12/19）、AWS re:Invent 2020におけるのDr. Werner Vogels（ヴァーナー・ボーガス氏）のキーノートは皆さんご覧になられたでしょうか。 氏のキーノートセッションは毎回恒例ですが、例年だと開発環境や実行環境・AWSインフラについての話にフォーカスがあたっている印象でした。その中で「Everything fail, all the time」や「You build it, You run it」のような名言・格言が語られてきました。 ところが今回は「Developer Keynote」と銘打った上で、よりオペレーション段階の話に長く時間が割かれました。MLやインフラに特化したキーノートが別にあったことも要因のひとつでしょう。 どんなことが語られたのか？ 個人的に気になったキーワードをひろってみました。 なお記事中の訳は基本的にぼくの解
![[レポート] オペレーション、監視(Monitoring)、可観測性(Observability)… AmazonのCTOはAWS re:Invent 2020のキーノートでどう語ったか？ キーワードを拾ってみた #reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/6ff0ae3d489a3ff18121e329779daf6be5562ed5/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F01%2F202012-report-reinvent-keynote-observability-eyecatch.jpg)
初めましての方は初めまして。お久しぶりの方はお久しぶりです。虎の穴のY.Mです。 このブログが始まった頃に、よく記事を書いていました。 月日は流れて、現在はEC開発のリーダーをやっております。 今回は技術的な内容というよりは、開発プロセスの内容を少し書きます。 書こうと思ったワケ 弊社のブログを眺めていたところ、これまで虎の穴の開発文化を紹介したことがなかったなと感じました。 チームでの開発をする上では、技術力はもちろん大事ですが、そのチームの開発文化が品質に大きく影響してきます。 ブログを読んでいただいている皆さんに、少しでも「こんな仕事のやり方をしてるよ」というのを知ってもらうべく、久しぶりに筆をとりました。 今回はそのとっかかりとして、一番エンジニアが頭と心を痛めるであろう『障害の事後対応』について書きます。 せっかくオタクエンジニアとして書くので、ちょっとゲーム仕立てにしてみます。
こんにちは、田中裕一です。今回Jeffery Smithさんが書かれた「Operations Anti-Patterns」という書籍の日本語訳を「システム運用アンチパターン」として出版します。 発売日は4/12ですが、一部の書店では既に店頭に並んでいるようですし、オンラインでも買えるようになっています。是非一読いただけると嬉しいです。 どういった本か本書を一言で言うならDevOpsによる変革を実践する人のための一冊です。ただ、そういった書籍は「Effective DevOps」や「The DevOpsハンドブック」など、これまでもありました。そういった書籍との違いは本書についての紹介に表れています。 本書は、技術チームの運用担当や開発担当のチームリーダーや一般のエンジニアを対象としています。より上位のマネージャーやシニアリーダーも本書から多くの有用なヒントを得ることができるでしょう。しかし
Aurora MySQL 5.6のサポート終了とゼロダウンタイムアップグレードへの挑戦 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、グローバル向けAWS版kintoneのバックエンドエンジニアをしている@ueokandeです。 8月になって暑い日々が続きますね。そして8月と言えば、Amazon Aurora MySQL-Compatible Edition version 1 with MySQL 5.6 compatibility（以下Aurora MySQL 5.6）のサポート終了までおよそ半年となりました。 グローバル向けAWS版kintoneでは、Aurora MySQL 5.6を採用しているバックエンドサービスがいくつかあり、チームで移行作業に取り組んできました。この移行作業は単なるアップグレードだけではなく、ダウンタイムなしでデータベースを移行するチャレンジにも取り組みました。この記事ではAmazon Auroraの移行作業の全貌と、移行戦略を紹介します。 Aurora MySQL 5.6のサポ
何か Kyashでサーバサイドのエンジニアをしているhirobeです。 業務でサーバサイドのアプリケーションへのfeature flag導入を提案および設計をしました。 どのような設計や実装にするか、なぜそうしたかを整理します。 なお、アプリケーションの特性としては以下を念頭に入れていただければと思います。 新規プロダクトではなく、5年以上動いている既存プロダクトに導入する サーバサイドアプリケーションのみをスコープとする 20~30のマイクロサービスから構成されている マイクロサービス間はREST/gRPC/SQSで通信されている そもそもなぜ導入するのか？ 目的を整理しておきます！ featureブランチからmainブランチにmergeされるまでの期間が長いために、以下のような問題がありました。 複数の機能開発の修正がconflictする可能性があり、またそれに気づくのが遅れる可能性が
広告技術部のUT@mocyutoです Gunosyではニュース記事を配信運用するメディア部門とアプリ上などに広告を配信運用する広告部門があります。 （本記事では「メディア」とはグノシーやニュースパスなどのサービスを指し、「広告」はそのメディアに出す広告を指します。） 今回は広告部門が運用している広告システムのスケールの仕組みについて紹介します。 課題 解決策 仕組み スパイクスケーリング スケジュールスケーリング スケールのロジックを記述 まとめ 課題 メディア側のシステムは各サービスごとにチームが分かれており、それぞれ別のシステムで稼働しています。 しかし、広告側のシステムは単一のシステムで動いており、各メディアの広告配信すべてを担っています。 そのため、サービスが増えるごとにトラフィックが増える仕様になっています。 特に速報などのプッシュ通知をメディアが送信すると一気にユーザはアプリを
小さなチームでのDevOps
はじめに これは"小さなチーム"でDevOpsを実践する際のアイデアのポストです。 DevOpsとは、運用の知識を開発に取り入れるマインドセットであり、またそのためのプロセスやアプローチを指します。ここでの"小さなチーム"というのは開発担当と運用担当とが分かれていないようなチームを指します。 DevOpsというとよく言及されるのは開発担当と運用担当のIntegrationの話だったり、DevOps専任チームの話や、DevOpsツールに言及するものが多いかと思うのですが、今回は開発担当と運用担当とが分かれていないような"小さなチームにおけるDevOps"についての話となります。表面的な事象の裏側にある構造上の特性を考えてみます。 "小さなチームでのDevOps"の場合には、DevとOpsの２つのミッションが１つのチームに集約統合(Consolidation)されています。全員が同じミッション
はじめに こんにちは。webエンジニア社会人をしている ningenMe です。 タイトル通り。MySQLで3億レコード物理削除した話。 ちょっとハマったので備忘録。 はじまりはアラート はじまりはアラートだった。 僕が運用・保守しているバッチサーバでは、mysqlからちょうど直近1ヶ月分のデータを毎日1回selectする定期処理をしている。 いつもなら1時間程度で終わる処理のはずが、その日は7,8時間経っても終わらずアラートが鳴り止まない.....。 原因追求 とりあえずリトライしたり、ログ見たりしたもののあんまり悪いところがなかった。 クエリもちゃんとindex効いてる。なんでだろうと思ったらDBの容量が結構大きくなっていたことに気づいた。 3億5千レコード。インデックスちゃんと効いてたので多分普通に遅いだけっぽい。 必要なデータ取得は1ヶ月分である12'000'000件ほど。このse
連載目次 MLOpsコミュニティーは「全ての機械学習モデルが現場で実運用化される世界」を目指して2020年夏に始まりました。月1回程度の頻度での活動を目指し、勉強会やワークショップ、ディスカッションなどを行うことで、今後のAI技術の発展に非常に重要な、MLOps（機械学習の実運用化）の普及に貢献していきます。 このレポートでは、2020年8月に行われた第1回勉強会の様子をお伝えします。300人以上の参加者がリモートで参加し、大盛況のイベントとなりました。当日の様子はツイッターでも盛んにつぶやかれ、こちらにそのまとめがあります。 なぜ今MLOpsなのか by シバタアキラ はじめに、オーガナイザーチームの一人である、DataRobot Japanのシバタアキラから、なぜ今MLOpsが注目されているのかをお話しました。まず300人以上にGoToWebinarのアンケート機能を使って質問しました
SRE for single-tiered software applications | Google Cloud Blog
In cloud operations, we often hear about the benefits of microservices over monolithic architecture. Indeed, microservices help manage hardware being abstracted away and push developers towards resilient, distributed designs. However, many enterprises still have monolithic architectures which they need to maintain. For this post, we’ll use Wikipedia’s definition of a monolith: “A single-tiered sof
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフーのプロダクションネットワークの設計・構築・運用を担当している津秦です。 ヤフーではオンプレミスで大量に物理サーバーを導入し、社内向けプライベートクラウドや、データ分析基盤などに利用しております。もちろんそのサーバーを接続するためのネットワークも、自分たちで設計・構築・運用を行っております。 今回はデータセンター内ネットワークの中でも、最近取り入れているClosネットワークというものに着目して、ヤフーのデータセンターネットワークをご紹介したいと思います。 なお、大量に物理サーバーを導入する点では、昨年末に同じくインフラを担当する藤見から、サーバーの調達に関する取り組みを紹介しました。合わせて参照いただければ、ヤフーのインフラ部
Post-Incident Review on the Atlassian April 2022 outage - Atlassian Engineering
This PIR is available in the following languages:日本語 | 简体中文 | 繁體中文 | Deutsch | English | Español | Français | Italiano | 한국어 | Polski | Português | русский. Letter from our co-founders & co-CEOs We want to acknowledge the outage that disrupted service for customers earlier this month. We understand that our products are mission critical to your business, and we don't take that responsibility light
美容クリニックは新規体制用の少人数体制で開発を行っており、その内の約 7 割がアプリ開発をしているエンジニアとなっています。 一方で、SRE は全体の約 1 割の人数しかいないという状況にあります。 この SRE の人数が少ないかどうかは扱っているシステムの規模や課題によって評価が変わるかと思いますが、美容クリニックが現在抱えている課題の量に対しては少ない人数だと感じています。 では、このように限られた人数の中でどのようにして SRE 活動を行ってきたのかを紹介していきます。 SRE チームの組閣 美容クリニックのリリース以前から SRE チームは存在していたのですが、リリース前後でその責務は変わってきます。 例えばリリース前はインフラの初期構築がメインの責務となってきますが、リリース後（エンハンス開発）にはインフラの保守運用がメインの責務となります。 さらに、メンバーの変動などにより当初
DevとOpsの対立 川口恭伸氏（以下、川口）：2009年からDevOpsが出てきます。 DevOpsの話、これは源流の「10+ Deploys per Day」というものがあって、ビデオを見ながら私が書き起こしたので紹介したいんですけれど。2009年に何が起きたか、どんな話だったかです。 「10+ Deploys per Day」は、1日に10回デプロイするというタイトルです。これはたぶん彼らの中で使っていたクラウドの話だと思うんですが、効率的なデータセンターを使い、デベロッパーと運用者が協調しながらガンガン10回デプロイできるようにするみたいな。それでも品質が壊れないようにするみたいな話が出ていて。 その時に、「じゃあどうやってみなさんは協調するのか」という技術論や文化の話が非常におもしろくて、DevOpsに興味がない方もぜひこれは1回見てもらいたい。特に、AWSとかインフラとかに近い
[アップデート] Amazon EC2 Auto Scaling で Auto Scaling Group 内のインスタンスを最新化できるようになりました！ | DevelopersIO
こんにちは、大前です。 久々に AWS MediaServices 以外の記事を書く気がします。 今回は、掲題のアップデートの紹介です。 Amazon EC2 Auto Scaling now supports Instance Refresh within Auto Scaling Groups どんなアップデートか Amazon EC2 Auto Scaling（以下 Auto Scaling）にて Auto Scaling Group 内のインスタンスを最新化する事が出来るようになりました。 今まで、 Auto Scaling Group の起動設定を変更（例えば、AMIの更新など）した後に既存のインスタンスを最新化するには一手間が必要だったりしたのですが、今回追加されたこの機能を使用するだけで、最新の起動設定で起動されたインスタンスに置き換える事が可能となりました。 今まで痒かった
![[アップデート] Amazon EC2 Auto Scaling で Auto Scaling Group 内のインスタンスを最新化できるようになりました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/bede2890e86b4906b777253ed659fb2dc79aeed0/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-ec2-auto-scaling.png)
GitHub - eugeneyan/applied-ml: 📚 Papers & tech blogs by companies sharing their work on data science & machine learning in production.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
piqcy on Twitter: "品質の担保されたPythonプロジェクトを作るためのチェックリスト。Pythonのバージョン/パッケージ管理からコメント、テストの書き方、カバレッジの計測にGitHub ActionによるCIの設定まできっちり書かれている。 https://t.co/4VqOHFGL8K"
品質の担保されたPythonプロジェクトを作るためのチェックリスト。Pythonのバージョン/パッケージ管理からコメント、テストの書き方、カバレッジの計測にGitHub ActionによるCIの設定まできっちり書かれている。 https://t.co/4VqOHFGL8K
地道に積み上げるSRE 目的合意から進めたSREの探求と実践｜グロービス・デジタル・プラットフォーム
今回の記事では、SREとは何なのかについて根本から考えながら活動してきた、グロービス SREチームの探求と実践について紹介します。 はじめにグロービス・デジタル・プラットフォーム SREチームでチームリーダーを務めている沼田（@chroju）です。 突然ですがSREとはどう定義されるでしょうか。この問い、存外に難しいのではないかと感じています。インフラエンジニアは「インフラ領域を担当しているから」そう呼ばれますが、ではSREは「サイト信頼性を担当しているから」そう呼ばれるのでしょうか。サイト信頼性を担当する、とは、具体的にはどういうことなのでしょうか。 SREチームの業務内容や責任領域は広範囲に渡り、おそらく会社によって様々な形を取っているのではないかと思います。2021年9月に日本語版が発売された『SREの探求』は、まさにそういった様々なSREの実践をまとめた書籍であり、冒頭の「はじめに
Product { this.openCategory = category; const productMenu = document.querySelector('.product-menu'); window.DD_RUM.onReady(function() { if (productMenu.classList.contains('show')) { window.DD_RUM.addAction(`Product Category ${category} Hover`) } }) }, 160); }, clearCategory() { clearTimeout(this.timeoutID); } }" x-init=" const menu = document.querySelector('.product-menu'); var observer = new Muta
医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスでサービス横断で技術的な課題を解決して回っている@okazu_dmです。 直近はSREとしての業務などがメインでしたが、本日は私が運用を担当していた全社横断の利用規約とプライバシーポリシー(以下、利用規約等とします)の管理&配信サービス(以降、社内のコードネームであるnomosと呼びます)について紹介します。 nomosとは nomosは、上述したとおり利用規約等を管理、配信するサービスです。2019年の夏には一旦開発が完了した段階で私が引き継ぎました。引き継ぎから実際に活用されるまでは半年ほど間があり、その時間はシステムの一部を単純化、再実装するなどブラッシュアップに使っていました。大まかにどのような変更があったのかについては後のシステム構成の説明の中で適宜触れます。 nomos
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
GitHub - upgundecha/howtheysre: A curated collection of publicly available resources on how technology and tech-savvy organizations around the world practice Site Reliability Engineering (SRE)
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分析基盤と組織のあり方 - DeNAの事例
なぜセキュリティを言い訳にアジリティが犠牲になるのか - 流沙河鎮
メンテナンスウィンドウを使わない - @katzchang.context
先駆者に学ぶ MLOpsの実際
運用の考え方は「システム管理」から「サービス管理」へ ITIL4で変わってきた、運用者に求められること
クラウドのシステム運用技術に機械学習を応用する研究 / CLOUD AI
Gitで継続的デリバリーを実現する「GitOps」とは？ 概要とGitOpsソリューションの紹介
稼働中の商用ネットワークでVRRPの切替検証を実施しちゃった話 - Qiita
メルカリにおける分析環境整備の取り組み - Speaker Deck
Python で緊急対応時の Slack 操作を自動化してみた | DevelopersIO
障害の対策というゲーム その進め方 - 虎の穴開発室ブログ
「システム運用アンチパターン」という書籍を翻訳しました｜yuichielectric
軽量feature flag導入の手引き - Qiita
10倍スパイクの速報時に耐えうるAPIのスケーリングの仕組み - Gunosy Tech Blog
MySQLで3億レコード物理削除した話 - Qiita
第1回勉強会：なぜ今MLOpsなのか、先駆者や実際の現場からMLOpsを学ぼう
データドリブンなサービスを支えるネットワークの作り方〜 ヤフーのデータセンターネットワーク紹介
「ホットペッパービューティー」美容クリニックでのSRE活動
たとえ障害の根本原因であっても“変化”を起こせることが大事 DevOps実現のための6つの方法と4つの文化
PHP 8: Observability Baked Right In
コーポレートの課題をエンジニアが解決した話 - エス・エム・エス エンジニア テックブログ
Using GitHub Actions for MLOps & Data Science
note.com/40sbestmake
l.smartnews.com
l.smartnews.com
l.smartnews.com
satori.marketing
manacomicsmania.hatenadiary.com