タグ

ブックマーク / muziyoshiz.hatenablog.com (9)

  • WEB+DB PRESS Vol.132「コンテナ化実践ガイド」はこれからコンテナ化する人必読の記事(のつもりで書きました) - 無印吉澤

    日12/24発売のWEB+DB PRESS Vol.132に、私が執筆した「コンテナ化実践ガイド」が掲載されました! 今までいろいろ文章を書いてきましたが、実は、書店に並ぶ雑誌に記事を書いたのは初めてです。ドキドキしながら発売日を待ってました。 gihyo.jp ちなみに、電子版がほしい方はGihyo Digital PublishingのEPUB/PDFセットがおすすめです。 gihyo.jp 想定する読者は? 歴史の長いシステムで、モノリシックなアプリケーションを開発・運用している方に向けて、コンテナ化を進めるためのステップを具体的に解説したガイドです。 ここまで具体的に(悪く言えば泥臭いことを)説明している資料は、少なくとも僕は見たことがないので、これからコンテナ化に着手する人には必ず役立つと思います。「うちのシステムをコンテナに乗せて、当に動くのか……?」と悩んでいる方に是非読

    WEB+DB PRESS Vol.132「コンテナ化実践ガイド」はこれからコンテナ化する人必読の記事(のつもりで書きました) - 無印吉澤
    fumikony
    fumikony 2022/12/25
  • AWSの薄い本シリーズ(IAMのマニアックな話など)の読書メモ - 無印吉澤

    年明けから IAM 周りの整理をいろいろしなければいけなくなったので、佐々木拓郎さんの「AWSの薄い」シリーズ2冊を読みました。今回はその読書メモです。 booth.pm booth.pm AWS は普段から使っているので、IAM の基的な機能はもちろん知っているのですが、最近追加された機能(特にマルチアカウント管理に関する機能)については全然追えてなかったので勉強になりました。 以下、勉強になった点をまとめたメモです。AWS の情報は日々変わっていってしまうので、発行日も併せて記載しました。 AWSの薄い IAMのマニアックな話(発行日:2019年9月22日) 第1章 AWSとIAM AWS Organizations は書の対象外 ポリシー記述の文法的な部分は書では扱わない。詳細は公式のIAM JSON ポリシーのリファレンス を参照 第2章 IAMの機能 IAMの機能のうち

    AWSの薄い本シリーズ(IAMのマニアックな話など)の読書メモ - 無印吉澤
  • SRE NEXT 2020 にスタッフ参加しての感想(ロゴデザイン、CFP レビュー、司会などの裏話) - 無印吉澤

    SRE NEXT ご参加いただきありがとうございました! sre-next.dev 1月25日(土)に、SRE に関する国内初の大規模テックカンファレンス、SRE NEXT 2020 が開催されました。私も、こちらのイベントにコアスタッフとして参加していました。参加者、登壇者、スポンサーおよびすべてのスタッフの皆様、当にありがとうございました。お疲れさまでした! 発表内容は全然聞けていない(詳しくは後述)ので、内容についての感想はまだ書けません。しかし、「参加ブログを書くまでが SRE NEXT」と言われてしまったので、取り急ぎスタッフとしての感想を書いてみます。 スタッフ参加の経緯 元々 SRE Lounge のボランティアスタッフだったので、こういうイベントを開催したいというアイディアは北野さんや小熊さんから聞いていて、最初から参加させてもらってました。 格的に動き出したのって、4

    SRE NEXT 2020 にスタッフ参加しての感想(ロゴデザイン、CFP レビュー、司会などの裏話) - 無印吉澤
  • 2019 年に SRE をしながら考えが変わったこと - 無印吉澤

    今回の記事は年末スペシャルです。 僕が SRE をしながらやってきた取り組みについては、今年も会社のテックブログに色々書かせてもらいました(職場の理解のおかげです。いつも感謝してます)。 ただ、それぞれのブログ記事の間を埋めるストーリーというか、その背景にあることについてはなかなか書く機会がありませんでした。なので、今回はそれらの記事を引っ張りながら、今年 SRE をしながら考えていたことをつらつらと書いていこうと思います。 この1年で考えが大きく変わったこと SRE のあるべき組織体制について、1年前はこう考えていました。 複数の開発チームをまたぐ形で SRE をマトリックス的に配置して、SRE はアプリの開発状況を細かく把握しながら監視・運用すべき ただ、この1年で考えが変わり、いまはこう考えています。 SRE をマトリックス的に配置するのは、確かに、開発速度を一時的に上げるのには効果

    2019 年に SRE をしながら考えが変わったこと - 無印吉澤
  • SRE はサービス品質に影響しない程度の異常をどう扱うべきか? - 無印吉澤

    今回の記事は、最近考えていたことのメモです。 ここ最近いろいろ考えていたのですが行き詰まってきたので、とりあえず課題意識を説明する文章だけ書いてみました。結論はまだありません。 障害と異常の定義 話の前に、障害(failure)および異常(anomaly)という単語を定義しておきます。人によって定義は違うと思いますが、自分が文章を書くときは以下のように区別しています。 障害:サービスの停止や、サービス品質の深刻な劣化を引き起こすようなインシデント 異常:サービスに対する深刻な問題は引き起こさないが、通常は起こらないはずのインシデント この定義をもう少し詳しく説明するために、例として、ロードバランサと、その背後に5台のアプリケーションサーバがあるシステムを考えます。 これらのサーバが5台ともダウンしたり、半数を超える3台がダウンして応答時間が極端に長くなった(例えば10秒以上になった)場合は

    SRE はサービス品質に影響しない程度の異常をどう扱うべきか? - 無印吉澤
  • Nginx でリバースプロクシを立てるときに気にすべき proxy_next_upstream 設定 - 無印吉澤

    個人的に、Nginx で「これは危険だ」と思っている設定があって、Nginx でなにかあるたびにその設定をつい疑ってしまいます。その設定について他の人に話すたびに、いちいち資料を集めるのが面倒になってきたので、今回はその設定項目についての情報をまとめておきます。 まだ理解に自信がない部分があるので、新しい情報が入ってきたら、この記事を適宜修正します。 リバースプロクシ設定の基 Nginx をリバースプロクシとして使う時には、ngx_http_upstream_module でサーバのグループを定義します。そして、サーバ名やロケーション(パス)に対して、送信先のグループを指定します。 以下はマニュアルにある例です。その Nginx サーバへのすべてのアクセスを、backend グループに指定されたいずれかのサーバに送信します。 upstream backend { server backe

    Nginx でリバースプロクシを立てるときに気にすべき proxy_next_upstream 設定 - 無印吉澤
  • 信用できる社内 Wiki をつくるために守ってほしい、たったひとつのルール - 無印吉澤

    このページについて この記事は、以前書いた「社内Wikiに情報を書くときに守ってほしい、たったひとつのルール」の続編です。前回は、個々のページをどう書くべきかという話をしましたが、今回は社内 Wiki 全体を信用できるものにする方法について考えます。 muziyoshiz.hatenablog.com 想定する環境 この記事は、ソフトウェア開発プロジェクトに関する Wiki が社内にあって、そこに各人がドキュメント(仕様書や手順書など)を書けるようになっている環境を想定しています。 私自身、ソフトウェア開発のときしか Wiki を使わないので、具体例もそのような環境に寄っています。ただ、ある程度は社内 Wiki 全般に通じる話かと思います。 ルール:「更新され続ける」ページと「更新されない」ページをはっきり分ける ここ1年ほど社内プロジェクトをいくつか渡り歩いていたのですが、個人的には、こ

    信用できる社内 Wiki をつくるために守ってほしい、たったひとつのルール - 無印吉澤
  • Fluentd Meetup 2016 Summer レポート 〜 v0.14 の新機能からプラグイン開発者向け API まで - 無印吉澤

    イベント名:Fluentd Meetup 2016 Summer 開催日時:2016-06-01(月) 会場:イベント&コミュニティスペース dots. 約1年ぶりに開催された Fluentd Meetup に参加してきました。今回は、5月31日にリリースされたメジャーバージョンアップの v0.14 について、ユーザ向けの機能紹介から、プラグイン開発者向けの深い話まで、盛りだくさんの内容でした。自分でプラグインを書くくらい、Fluentd をヘビーに使う人向けのイベントという感じで、どの話も面白かったです。 最近、私は Fluentd を使う機会が全然なかったこともあって、「Fluentd も機能的には枯れてきて、そろそろ新機能もあまりないだろう」と思っていたのですが、まだこんなに改善の余地があったのか……とちょっと驚きました。個人的には、古橋さんの講演で将来の構想として出てきた、Kafk

    Fluentd Meetup 2016 Summer レポート 〜 v0.14 の新機能からプラグイン開発者向け API まで - 無印吉澤
  • 社内Wikiに情報を書くときに守ってほしい、たったひとつのルール - 無印吉澤

    このページについて これは、社内 Wiki に情報を書くときに、私が個人的に守っていて、チームメンバにもできるだけ守ってほしいルールの紹介記事です。このルールを実際に運用するためのコツについても、基ルールの派生という形で紹介します。 想定する環境 この記事は、社内に Wiki があって、フォーマットが決まったドキュメント(仕様書や手順書など)とは別に、各人がメモを自由に書いて共有できるような環境を想定しています。 Wiki の種類は問いません。PukiWiki、MediaWiki、Confluence、Esa、Redmine などのプロジェクト管理ツール付属の Wiki などなど……何でもいいです。Word 文書などにも適用できなくはないですが、文書を気軽に分けるのが難しい場面には、あまり向かないかと思います。 ルール:「このページについて」という欄をページの先頭に用意し、そのページの概

    社内Wikiに情報を書くときに守ってほしい、たったひとつのルール - 無印吉澤
  • 1