システムをVMからコンテナに移行して、結局VMに戻した話 - MonotaRO Tech Blog
こんにちは、モノタロウ コアシステムエンジニアリング部門 配送ドメイングループの安見です。 この記事では私が関わっていた社内システムを仮想サーバ(AWS EC2)からコンテナに移行した後にコンテナをやめて仮想サーバに戻した話をご紹介します。 諸説明 コンテナ移行について コンテナ化対象システムについて 直面した様々な問題 リリース後の多数の残課題 展開する機能の数が多すぎる コンテナ化のメリットが薄かった なぜこうなったか よかったこと まとめ 追記： 現在なら... 諸説明 コンテナ移行について システムのコンテナ移行とは、アプリケーションやサービスを動作させるための必要なすべての環境を、一つの「コンテナ」としてパッケージ化して動作できるようにすることです。これにより、アプリケーションは他のシステムと独立して実行され障害分離ができたり、環境の違いによる影響を受けにくくなるため移植性が向上
現職での技術的活動の振り返りと反省（自戒） | ymtdzzz.dev
2024年6月30日に今の会社を退職し、翌7月1日から別の会社に入社することになった。 現職の在籍期間は大体３年弱ほどで、アーキテクチャを中心とした技術的な意思決定も色々してきた。新規構築から運用までやってきた中で感じたことや経験豊富なエンジニアからいただいたアドバイスなど、それらを含めて当時の意思決定の反省を自戒を込めてここで書いておく。 Table of Contents 留意事項 やったこと 想定効果 基盤チーム側の効果 サービス開発（基盤のクライアント）側の効果 意思決定 技術スタック コード管理 インフラ その他 所感と教訓 コンポーネントとリポジトリの粒度は別 複雑性を犠牲にする決断の重さ（マルチクラウド、マイクロサービス etc.） 共通基盤を初めから独立したサービスとしてデプロイしないのもあり サブシステムとしての共通基盤にどこまで粗結合を求めるべきか考える 結論：後から分
エンジニア主導で爆速開発を実現する - Tabelog Tech Blog
はじめに こんにちは。食べログ開発本部 ウェブ開発1部の羽澤です。 マネージャーという立場で働いておりまして、案件をリードしたり、一歩引いてメンバーや案件をサポートしたり、その時々で役割を変えながら日々過ごしております。 その中でいつも頭を悩ませているのが、いかに早く開発を進めるかということです。これは食べログだけでなくどんな組織でも常に考えている、永遠の課題だと思います。 今回は食べログの開発体制を紹介しながら、自分として爆速で進められたと感じている案件を紹介します。「なぜうまく行ったのか」を掘り下げることで見えてきた重要な視点を、「爆速で進める1つのポイント」としてまとめてみました。 プロジェクト体制の紹介 開発の話の前に、前提となる組織の形を紹介します。 私の所属するウェブ開発1部では、マトリクス型の組織を採用しております。 ウェブ開発1部の事例ではありませんが、以下の記事が参考にな
メンテナンス画面の表示方法いろいろ | 外道父の匠
コンテナの話（AWSコンテナ系アーキテクチャの選択肢を最適化する）をした時にメンテナンス画面の表示についても軽く触れました。 改めて整理すると他にもいろいろあるということで、上から順に超ザックリと並べていきたいと思います。一応 AWS でを想定していますが、一般的な方法論でもあるので、どこだろうと何かしらの足しにはなるかもです。 条件 どのようなメンテナンス状態にしたいかによりますが、満たすべき条件はおそらくこのようなものがありますよ、ということで整理します。 １回の変更操作で、一括したメンテインを保証すること 管理者はメンテにならず通常アクセスする手段があること メンテ機能の仕込みによって悪影響がないこと 希望するメンテ用レスポンス内容を実現可能であること 静的 or 動的 Status Code 503 Content-Type レスポンス・サイズ 例えば DNS のレコード値を変更し
はてなで最近実施しているSRE研修の紹介 - Hatena Developer Blog
システムプラットフォームチームで SRE をしている id:masayoshi です。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の7月号です。先月は id:chaya2z さんの AWS ECS で実行するバッチ処理を Cluster Auto Scaling を使ってコスト最適化する でした。 今月は、社内で最近始めたSREへの研修についてお伝えします。 SREの研修 SREの研修は新卒入社のSREや、中途採用でインフラエンジニアやアプリケーションエンジニアからSREにジョブチェンジした方を対象に実施しています。 SREの研修は主に以下の2つに分かれます。 SREの原理原則やSLI/SLOに関する研修 インフラ構築、運用、CI/CD環境の構築に関する研修 基本的にはどちらも受けてもらうことになりますが、受講者の経験によってはどちらかだけになることもあります。 ま
ゼロから始めるシステム障害対応フロー - Qiita
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が（ほぼ）ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO：プロダクトオーナー（Pd
運用設計における設計項目の体系化 / 20240207-ssmjp-operation-design-items
ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
SRE を立ち上げた4ヶ月後の世界
この記事は、Magic Moment Advent Calendar 2023 4 日目の記事です。 こんにちは! Magic Moment で Senior Engineering Manager 兼 SRE Engineering Manager をやっている 木村 (@ryurock) です。 Magic Moment アドベントカレンダー 4 日目では、2023年9月に SRE チーム を立ち上げた 4 ヶ月後の世界。 というテーマでアドカレやっていきたいと思っています。( ｰ`дｰ´)ｷﾘｯ SRE チームの立ち上げの経緯 遡る事、2023年7月頃に弊社が提供しているサービス Magic Moment Playbook のコアデータが立て続けに更新できない障害が相次ぎました。 Sales Operation を行う上で、大切なデータが頻繁に反映されないこの由々しき事態はユーザー様
どうしてもドメインを永久保持できない企業向け 企業はどうドメインを捨てるべきか - Web > SEO
コロナ禍中に取得された地方自治体のドメインがオークションで高値売買され、中古ドメインとして悪用されるなど、公的機関のドメイン放棄問題が注目されています。 11月25日のNHKニュース7でドメイン流用の件が報じられました。私も取材を受け少しご協力をしています。 www3.nhk.or.jp 公的機関のドメイン放棄問題の理想の解決は、今後は lg.jp、go.jp などの公的機関しか使えないドメインだけを使うようにすることです。 ただ今回の問題はコロナ禍初期の大混乱時、非常にスピーディにサイト立ち上げが求められていた時の話です。 信頼が求められる lg.jp などのドメインの利用には厳格なルールがあるのも当然です。あの混乱時期にルール改定も難しかったと思います。新規ドメインが選ばれた事は仕方がない事と思っています。 ただ、コロナ禍が落ち着いた今、無責任に放棄されるのは明らかな問題です。 今回の
システム運用はお金で解決したい、ができなくなってきている - orangeitems’s diary
ビジネスは基本的に成長していくものだし、拡大していくことが前提で、しかも最近だと「システム」が付いてくる。全部人力で作り上げるビジネスなんてあるのか。いや、ない。あるとしても小規模だろう。人だけで成り立つなんてビジネスを放置しても、きっともはや、人が集まらない。コンピューターによる自動化はない。全部人力だ。さあ仕事しなさいって、それは原始的だろう。あらゆる仕事場で自動化ありきの人間の仕事が増産されているのであり、人々もそういう職場を狙っている。時代遅れの職場で、かつそういう人力の仕事は生産性も低く給料も安いので、どんどん敬遠されるようになる。 さて、じゃあシステム化しました、と。システム化するための要員はまだいるようだ。各社ベテランが腕を奮っている。DXの掛け声でクラウドもあって生産性は上がり、システムと名の付くものが量産されている。わかっている、システム構築のスピードは10年前と比べると
ニンテンドーアカウント刷新プロジェクトの裏側 27カ月にわたる試行錯誤、キーパーソンが語る
ニンテンドーアカウント刷新プロジェクトの裏側 27カ月にわたる試行錯誤、キーパーソンが語る：AWS Summit Tokyo（1/2 ページ） 「スプラトゥーン3」「大乱闘スマッシュブラザーズSP」など、Nintendo Switch向けゲームのプレイには欠かせないサービス「ニンテンドーアカウント」。2015年のリリース以降、164カ国、約2億9000万人（22年9月時点）のユーザーに展開する大規模サービスだ。 しかしニンテンドーアカウントが現在の形になるまでには、その裏側で27カ月にわたる努力があった。実は2018年5月以降のタイミングで、ニンテンドーアカウントには予測できないアクセス集中や運用工程の増大といった問題に直面。システム改修を迫られていた。 「リリース以降も継続して機能開発を進めることができ、順風満帆だと思っていたが、そう甘くなかった」──システム改修を手掛けたニンテンドーシ
チームでフレームワークのバージョンアップに立ち向かうための考え方 - CARTA TECH BLOG
こんにちは、こんちゃん(@konchanSS)です。 Zucks アドネットワークでは広告配信プラットフォームの開発をしています。その中で、マイクロサービス的にいくつものサービスに分割されて運用されています。 cartaholdings.co.jp Zucksが大切にしているエンジニア文化はこちら 今回は、管理画面サービスで行ったフレームワークのバージョンアップについて書いていこうと思います。特に、進め方、考え方について伝えます。 今回バージョンアップを行ったのは、SymfonyというPHPのフレームワークです。 目次 バージョンアップにおける考え方 バージョンを上げて終わりではない。いかに上げやすく作っておけるかが大事 人の手による作業をできるだけ発生させない ユニットテストとE2Eで動作を担保する バージョンアップする際にビッグバンリリースをしない バージョンアッププロジェクトの進め方
100億レコード超のDBを“障害ゼロ”でマイグレーション 新卒1年目が考えた2つのアプローチと3つの工夫
インターネットやAIを駆使しながら、領域に捉われずにさらなる挑戦を行うDeNAの取り組みを紹介する「DeNA TechCon 2023」。ここで成田氏が登壇。PocochaのDBをマイグレーションしたことについて話します。 新卒1年目が100億レコード超のDBマイグレーションをした話 成田篤基氏：発表を始めます。みなさんはじめまして。成田と申します。私は2021年にディー・エヌ・エーに新卒で入社して、現在入社から2年が経とうとしています。 私は新卒1年目で、大規模なデータベースマイグレーションを行う貴重な経験ができました。本日はそのマイグレーションプロジェクトについて、体験から得た学びをみなさんにお伝えします。題して「新卒1年目が100億レコード超のDBマイグレーションをした話」です。どうぞよろしくお願いいたします。 目次です。本日はこちらの目次に沿って発表を進めていきます。 まずは私たち
[書籍レポート] 「オブザーバビリティ・エンジニアリング」はパワーワード満載の「『入門 監視』の次に読むべき本」だった | DevelopersIO
自分の関わるアプリケーションやインフラのモニタリングに困っている？ オーケイ、冒頭からアクセル全開の力強いワードにあふれたこの一冊を紹介するぜ！ はじめに 今年(2023年)の1月末に発売されたこちらの本、もう読まれたという方も多いのではないでしょうか！（挨拶 本記事は、まだ読まれていない、買ってもいないという方に向けて、「紹介しなきゃ」という謎の強い使命感をもって書かれています。 というのも、実は本記事の執筆者（ぼくです）は、300ページを越えるこの本のまだ半分ほどしか読むことが出来ていません。。！ *1 それでもこの本を紹介するモチベーションは十分です。なにしろ、この本は冒頭から、もっといえば「まえがき」の段階から、パワーワードにあふれた一冊だからです。引用してみましょう。 “（「オブザーバビリティ」という）用語が注目されるようになると、ある種の隣接性を共有する別の用語と互換的に使われ
![[書籍レポート] 「オブザーバビリティ・エンジニアリング」はパワーワード満載の「『入門 監視』の次に読むべき本」だった | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/e557ded8e0ecef2f687c73d647f86e0ce3cffd0b/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F02%2F202302-report-observability-engineering-eyecatch.jpg)
【個人開発】収益化したサービスのコードを50%以上削除して得られた境地
先に境地を 個人開発の場合、少ないコード・最低限のシステム構成は正義。 なぜなら、時間やお金に制限がある個人開発者にとってサービスの継続に関わる問題だからです。 例えば、自分のサービスを世に広めたいとか、一発当てたいとか、作ったサービスで生活をしたいとか、 なにか目標があるなら達成する方法は、達成するまでやめないことです。 なのでサービスを提供し続けることは最も大切なことです。 これまで個人開発者としては↓の気持ちで開発を進めてきました。 しかし、この経験の後にこの↓の名言の大切さを改めて感じることができました。 シンプルにしておけ愚か者 また、本記事本文より たくさんプラグインやモジュールを入れたシステムはメンテナンスがしんどいです。「デフォルトで使う」ということの魅力を改めて実感しています。リソースが限られている個人開発の場合、このような時間の消費は極力なくす方向にしていくべきです。
一見安定しているシステム運用の現場が、急に危機になる理由 - orangeitems’s diary
知床遊覧船の事故について、犠牲者のご冥福をお祈りするとともに、行方不明者の無事を願っています。 この件のバックグラウンドを調べると、学ぶべき話が聞こえてきた。 toyokeizai.net 観光船を運航する｢知床遊覧船｣（北海道斜里町）は､2020年末に退職した元船長の男性によると､21年3月までにスタッフ5人が辞めた。会社側の人員整理方針と意見が合わなかったためという。 他社の船長によると､大量退職後､知床遊覧船の船が岸に近づきすぎたり､定置網の近くを通ったりする様子が目撃され､｢操船技術が未熟だったようだ｣という。｢普通は座礁なんてしない。いつか人命に関わるような大きな事故が起きるのでは､と心配していた｣と話した。 この、ベテランが抜けたあとも経営を続けなければ行けないときに、そのときに年長である人が権限を握るも、能力がおぼつかない、この状況はITの世界でも起こりうる。 システム運用は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
10年続くサービスのデータを1日未満のメンテナンスウィンドウで安全に移管する
冬休みに「初めての自宅サーバー作り」を、1.8万円で買ったN100ミニPCにCasaOSをセットアップ【イニシャルB】
RDB無停止移行への挑戦 #データベース_findy
「一線」を越えた自宅サーバー管理者のあなたへ。よく使うルーターやサーバーを集めたダッシュボードを「Dashy」で作る【イニシャルB】
