リリース手法多すぎﾜﾛﾀｧ B/G、カナリア、機能フラグ、ダークローンチ、A/Bテスト、、など - Qiita
この記事でCloudWatch Evidentlyについて調べていると、「機能フラグ」や「A/Bテスト」などインフラエンジニアには若干聞き慣れないリリース用語が出てきました。 アジャイル開発やCI/CDの台頭に伴い多数出現したこれらのリリース戦略用語をまとめて整理してみることにします。 インフラエンジニアやSREと呼ばれるロールの方々も、リリース戦略を知っておくとCI/CD環境の構築やIaC、はたまたミドルウェアのバージョンアップなどで役立つと思います。 以下ウェブサイトを参考に、各用語を「デプロイ戦略」と「テスト戦略」の大きく2つに分けて紹介します。 デプロイ戦略 従来型のデプロイ（インプレースデプロイ） システム本番環境が一種類のみ存在し、新バージョンの資材デプロイによって旧バージョンの資材を上書いてしまうパターンです。 環境の設計や管理、維持コストをシンプルに抑えられるメリットがあり
ランニングコストほぼゼロから始めるスケーラブルな本番環境
はじめに 私は個人開発で一山当てたいと常々思っていて、そのためにいくつかヒットしそうなサービスのアイデアがあります。エンジニアであればアイデアを具現化することに躊躇してはいけないと思うわけですが、一度リリースしてしまうとランニングコストが発生するわけで、仮に全く人気がでなかったとしたらランニングコスト分の赤字を垂れ流すことになります。 一方、個人開発者というのはおそらく誰しも夢見がちなので、リリース後バズったりしてユーザーが大量に押し寄せてきてしまってサーバーダウンする可能性も考えてしまいます。 その結果、「全く誰も来なくてランニングコストが赤字になったらどうしよう」という不安と「めちゃくちゃバズってしまってサーバーダウンしてチャンスを逃したらどうしよう」という不安が、心の中でせめぎ合うことになります。 そこで、今回はその2つの不安を一気に解消する「使われなければランニングコストが限りなく
今すぐ ALB のアクセスログをクエリする - クックパッド開発者ブログ
クックパッドマートでサーバーサイドなどのソフトウェアエンジニアをしている石川です。 この記事では、クックパッドマートとは全然関係なく、私が正社員として新卒入社する前、2020 年初頭に技術部 SRE グループで就業型インターンをしていた際に実装したシステムについてご紹介します。 ALB のアクセスログ 弊社では AWS の Elastic Load Balancing (ELB) を多用しており、Application Load Balancer (ALB) が多くのウェブアプリケーションで利用されています。 ところで ALB はアクセスログを Amazon S3 に保存することができます。このアクセスログにはアクセス先の IP アドレスやリクエスト URL の他、レスポンスのステータスコード、レスポンスまでにかかった時間、User-Agent などの情報が記録されています。 これらの情報
データセンターの思ひで | 外道父の匠
今月、とうとうオンプレミス環境がその役割を終えたので、当たり障りのない範囲で思ひでを記録しておこうと思います。 だいたい 2002年 から運用が始まったので18年ほどの歴史でしたが、血と汗と…… 血と汗くらいですかね滲んでるのは。さぁ振り返りです。 大阪 私が参画した時にはインフラエンジニアというかサーバー担当者が既に１名おり、「サーバーやってみない？楽しいよ！」と言われて乾いた笑顔を返したのを覚えています。 当時は京都の極小ベンチャー企業で、なぜ最初が大阪のデータセンターだったのかは聞きませんでしたが、とある現地作業についていって、ハーフラック１台に１Ｕ２台が積載されていました。このへんは私自身かなりのペーペーだったので知識不足もあり記憶がかなり曖昧です。 平々凡々に運用していたある日、WEBサイトへのアクセスが途絶えました。 社長の「ねぇ、サイトに繋がらないんだけど」の一言が口火です。
AWSでAZ障害が起きたのでなるべく影響を受けない構成の考えを書いておく - なんかかきたい
AZ障害は受け入れるしかないクラウド時代のインフラ ただの日記。 今日の昼、AWSを利用している人たちは大変だったところもあると思う。 AZの一つが丸々機能しなくなる大きなAWSの障害があり、AWSを利用して運用されていたサービスは多かれ少なかれ影響を受けることになった。 完全に雰囲気で書いてしまうが、今回のAZ障害で影響を受けたサービスは思ったより多かったように感じる。 というのもAWSではアベイラビリティーゾーンの障害は発生するものと考え、本番運用するのであれば、マルチAZ構成を取るのがベストプラクティスとされているので、 マルチAZ構成を取っていれば影響なんてないんじゃないの普通、と思ってしまうと思う。 インフラ屋さんでもそう思ってしまうし、インフラ屋さん以外ならなおさらなんで重くなるのかわからないと思う。 幸い自分の運用しているサービスでは影響が軽微だったので、完全に想像にはなって
インフラエンジニアの独り言、ストレージは盲点になりがち - orangeitems’s diary
インフラエンジニアの世界 IT技術者というと世間から見たら、要件定義やシステム設計をおこなうシステムエンジニアと、それを実装するプログラマーしか見えてないと思うんですよね。でもその基盤を動かすインフラエンジニアという人たちが全体の10パーセント弱（肌感）存在しています。 インフラエンジニアと言ってもまたそこから役割分担があって、物理サーバーやOSに強いサーバーエンジニアと、ネットワークに強いネットワークエンジニアがいます。大昔は物理サーバーとネットワークしかインフラに無かったので、大体はこの二極化でした。ネットワークエンジニアはスイッチやファイアウォール、ロードバランサーくらいまでは自分の領域としてくれていますが、OSやミドルウェアのことになると、それは私の領域ではない発言が出てサーバーエンジニアをブチ切れさせること請け合い。逆にネットワークエンジニアはサーバーエンジニアがなんでもネットワ
「全然わからない。俺たちは雰囲気でコンテナをやっている」 /operating-containers-just-with-a-hunch
Hacker Tackle 2018 発表資料
25K request/secをさばいた「LINEのお年玉」のアーキテクチャの裏側 - LINE ENGINEERING
みなさんこんにちは、LINEのサーバーサイドエンジニアの長谷部です。普段は、最近でいうとLINE Login や LINE Customer Connect などの開発を担当しています。 2018年の年始に LINEのお年玉 というイベントを実施し、その開発を担当しました。今回の記事では、LINEのお年玉のアーキテクチャの紹介や、当日実際に発生した問題(サービス過負荷起因のkafka consumer遅延)などの振り返りについて書こうと思います。 LINEのお年玉とは お年玉イベント期間中に、お年玉とLINEスタンプをセットで「お年玉つきスタンプ」として販売しました。対象スタンプを購入したユーザーさんは、スタンプ購入数 x 10個 のお年玉が付与されます。 こういったメッセージが受信されます ユーザーは自分がもっているお年玉を友だちに直接送ったりグループに送信することができ、お年玉を受け取
失敗しないデータセンター設計のためのケーススタディ - Qiita
IaaSの中で構築などをしている者です。 データセンターの中にネットワークやサーバを作っていますが、データセンター設計1にはこれといった指針やベストプラクティスのようなものが（あるようで）実はあまりないため苦労することがあります。 検証環境でもない限り、データセンタに作ったシステムというのは、気に入らないからと言って、じゃあ止めて作り直すね、というわけにもまいりません。 特に物理的な問題は、後になってから「ああしておけばよかった」と思っても、後の祭りです。 クラウドを使っていれば、気にしなくても良いのですが、それでもコロケーションやオンプレミスに何か作らなければならなくなった方の参考に少しでもなればと思い、まとめます。 サーバとルータを同じラックに入れるのは有りか？ 何が問題なの？と思われるかもしれませんが、 結論を言えば、無しではないが極力避けるべき、です。 主な問題はこんなところです。
AWSの新サービス群に対する一行所感 - プログラマでありたい
今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。 AWS AppSync モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな？認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか？ 2017/12/3 追記 中の人曰く、次のような役割分担とのこと AWSの新サービス群に対する一行所感 - プログラマでありたい ありがたし / Cognito Syncは「一つのIdentityに（≒一人の人間）が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それ
第1回 Dockerとは
「Docker（ドッカー）」とは、非常に軽量なコンテナ型のアプリケーション実行環境である。dotCloud社（現Docker社）が開発し、2013年にオープンソースのプロジェクトとして公開された。ソフトウェアの高速な配布・実行や容易なイメージのカスタマイズ、導入運用の手軽さ、豊富なプレビルドイメージの提供などの理由により、当初はソフトウェアの開発やテスト段階における利用が多かったが、現在ではパブリッククラウドからオンプレミスシステムまで、さまざまなシーンで急速に普及しつつある。 軽量なコンテナ型の仮想化環境Docker 独立したアプリケーション実行環境といえば、PCのハードウェア全体を仮想化して、その上でOSやアプリケーションなどを動作させる仮想実行環境を真っ先に思い浮かべることが多いだろう。ハイパーバイザ型（Hyper-Vなど）やホスト型（VMware PlayerやWindows Vi
Googleは巨大なインフラをどうやってセキュアに保っているか。独自のセキュリティチップ利用やDoS対策、安全なソフトウェア開発など、全体像を解説したホワイトペーパーを公開
Googleのクラウドは間違いなく世界最大規模のコンピュータシステムです。膨大なハードウェアとソフトウェアから構成されるこの巨大なシステムを、同社はどうやってセキュアに保っているのか。そのことを解説したホワイトペーパー「Google Infrastructure Security Design Overview」が公開されました。 ホワイトペーパーには、Googleのデータセンターを構成するデバイスの1つ1つにまで独自のセキュリティチップを組み込んで正規のデバイスかどうかを相互に認証するという物理レベルのセキュリティから、何層のものロードバランサーからの情報を集約してDos攻撃を検知すると、その通信を破棄するといったDoS対策。 そしてマシンも従業員もサービスも包括するグローバルな名前空間など、きわめて広範かつ綿密なセキュリティ施策が説明されています。 クラウドがいかに高度なセキュリティで
「障害発生時に即座に収集したいサーバの状態・14項目」を実際に収集してみた - えいのうにっき
僕はインフラエンジニアではないし、そうだったこともないのだけど、いま「インフラエンジニアの教科書２」という本を読んでいる。 インフラエンジニアの教科書2 スキルアップに効く技術と知識 作者: 佐野裕出版社/メーカー: シーアンドアール研究所発売日: 2016/08/26メディア: Kindle版この商品を含むブログを見る Twitter かなにかでこの本の存在を知り、とりあえず買ってみたものの、しばらくの間積読状態になってしまっていた。...のだけど、最近になってようやくちまちまと読んでいる。関係ないけど、kindleで読めるのはほんとに便利だ。 この本の7章「障害対策と障害対応」で、『以下のような項目についてはサーバ障害時に即座に（20秒程度で！）収集できるべき』、とされていた。 メモリの搭載量と使用量 パーティションごとのディスクの使用率と空き容量 CPUの種類とコア数 ディスクのRA
マイクロにしすぎた結果がこれだよ！
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
はてなでの サービス信頼性向上のための 取り組み事例
SRE Tech Talks ( http://connpass.com/event/34825/ ) でお話した際の資料です
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービスメッシュを完全に理解する / Perfect Service Mesh
Infrastructure as Codeのこれまでとこれから/Infra Study Meetup #1
hatebu.me
PostgreSQL Performance Monitoring
インフラエンジニアの綺麗で優しい手順書の書き方
