個人で運用している VPS に Kubernetes を乗せて既存のシステム（Web アプリとか Slack Bot とか Cron ジョブとか）をガッと移行した。 もともとは itamae 使って Systemd でサービス立ち上げていたのだけど、ソフトウェア依存とか権限分離とか冪等性とか面倒になってきて、うおお Docker でデプロイするぞ！となっていた。 初めは Docker Compose で立てようと思っていたけど、k8s のほうが楽しそうなので k8s にした。実際楽しいので良いと思う。 何を使って Kubernetes を立てるか Microk8s メリット デメリット kubeadm メリット デメリット 他に考えたこと ネットワークプラグイン Volume 周り オブジェクト管理 アプリケーションの移行 感想・補足 何を使って Kubernetes を立てるか Micr

以下、ざっくり説明していきたいと思います。 > Web Server/Workerの移行Web Server/Workerの移行 従来はHeroku(US region)にサーバがあったため、日本からのアクセスの場合チューニングをどう頑張っても数百msの遅延がありました。これをAWS(Tokyo region)に移行することで、ページを表示するのに要する時間が1/2 ~ 1/3まで改善されました。 > DockerDocker 移行開始直後は自分が不慣れなこともあり、このタイミングでDockerを採用する気はありませんでした。しかし、実際にECS上でのデプロイを検証したり、Dockerについて学習するうちに移行のイメージが掴めてきたのでDockerを採用することにしました。 もともとHerokuで動いていて The Twelve-Factor App にほぼ沿っていたので、やってみるとDo

' sandbox="allow-same-origin" class="iframe__style--small-card" data-v-2fcdfb78> シンプルなフラットボタン

こんにちは。SRE の @chaspy です。 先日行われた SRE NEXT 2020 にて、SLO Review というタイトルで発表してきました。 本記事では、会場に来られた方には内容を追体験してもらえるように、来られなかった方には伝えたかった内容を持ち帰っていただけるように解説します。 来場者への質問 本セッションを聴きに来られている会場の方に、SLO に関する質問をしました。 会場への質問 SLO という言葉の意味を知っているひと：9割以上、ほとんど全員 自分のサービスに SLO を定めて運用をしているひと：2割程度 Error Budget Policy を定めて、SLO 違反になった際にリリースを止めるなどをしているひと：2,3人 事前に予想した通りの比率でした。まさに僕の発表は 1 を満たしているが、2をこれからやる、というひとに対するヒントを提供する発表だったからです。

個人的には、この考え方はとても興味深いものです。 SLO は 100% に近いほど良いもので、「目指せ 100% !!」 と考えがちですが、そうではなく障害などによる未達部分を除いた時間を余力・機会とし、本番環境でのリリース作業や改善を施すことが出来る数値的な目安とすることは、関係者間（開発者・運用者・ビジネスサイド）での合意形成をスムーズにさせてくれるはずです。 やってみる Web サービスからの レスポンスタイムを SLI とし、平均 5ms が 1ヶ月で 99.5% 満たすことを SLO とします。 Datadog Synthetics 作成 Synthetics API Test を利用して対象となる Web サービスを外形監視します。(手順は割愛します) Datadog Monitor 作成 SLO を利用するには、Monitor の作成が必要となります。 Monitors >

やりたいこと 解の一つ 参考 除外する UserAgent を設定 Web サーバーの設定（アクセスログの設定） 以上 やりたいこと ELB からのヘルスチェックログはログに記録したくないよ 解の一つ 参考 bjornjohansen.no 除外する UserAgent を設定 /etc/nginx/conf.d/log.conf map $http_user_agent $log_ua { ~ELB-HealthChecker 0; default 1; } Nginx のアクセスログ内では UserAgent は $http_user_agent という変数に格納されているので、map モジュールを利用してフィルタする。 Web サーバーの設定（アクセスログの設定） /etc/nginx/conf.d/app.conf server { listen 80; server_name l

本記事は、 Engineering Manager Advent Calendar 2019 の21日目の投稿です。 あなたはだれ スタディストという会社で、2018/9から SRE チームの Engineering Manager を担当しています。2019/9より開発組織全体の副部長を兼任し、活動をしています。 この記事を書く背景と目的 そこそこ昔から、チームや組織に関する書籍が好きで読み漁っていたのですが、 Engineering Manager になってから改めてそれらの書籍を読み返すと、これまでとは違った感じ方をできるようになりました。また、買った本の読み方も大きく変わったような感覚を持っています。そんな気持ちを皆さんとも共有したいと思い、私が最近よく読み返す書籍の中から、身に沁みた言葉・考え方をいくつか紹介したいと思います。何か1つでも参考になるアイデアがあれば幸いです。 En

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog みなさんこんにちは。 システム統括本部に所属し、プライベートクラウドのKaaS（Kubernetes as a Service）の担当をしている藤江です。 私は2007年にヤフーに新卒で入社し、会計システムや社内認証システムなどの業務システムの開発・運用経験を経て、2017年4月から今のKaaS運用業務をしています。 現在のプロジェクトではScrumを導入しており、プロダクトオーナーとして働いています。 さて、いきなりですが最初に質問です。Kubernetesというツールを知ってますか？　実際に業務で使っていますか？ 去年の1月に開催されたYahoo! JAPAN Tech Conferenceの登壇で、この質問をした時、会場で手

みなさん、こんにちは！ AWS事業本部の青柳＠福岡オフィスです。 re:Invent 2019、12/3 (現地時間) に行われた Andy Jassy Keynoteで、コンテナ界隈 (？) には待望の「Fargate for EKS」が発表されました。 私も早速「やってみた」ブログを公開しましたが、ごくシンプルなサンプルを動かしてみただけですので、イマイチ「ピン」と来ない方がいらっしゃるかもしれません。 (と言うか、私もピンと来ていないところがあります) また、「今までのEKSとどう違うの？」とか「何ができて何ができないの？」など、いろいろな疑問も出てくると思います。 (はい、私もいろいろ疑問が湧いてきました) そこで、まずは、公開されているドキュメントベースで「Fargate for EKSとは何ぞや？」について調べてみましたので、みなさんにご紹介したいと思います。 「Fargate

はじめに 本記事は「Top 5 container and Kubernetes best practices」のレポートです。 セッション概要 Yes, technologies like containers and Kubernetes can help make your software delivery processes easier and faster. However, these new deployment tools and orchestration methods are very different from a traditional environment in terms of management and monitoring. How should you architect your container so that it works the

1980年代末からゲーム製作に携わる。『シュタインズ・ゲート』を代表とする科学アドベンチャーシリーズの企画・原作を務めるかたわら、人気の作詞・作曲家としても有名。さらに、ドワンゴ取締役なども務める実業家の顔も持ち、その非凡な才で、幅広い舞台で活躍を続ける。（文中は志倉） ――まずは科学アドベンチャーシリーズを作ろうと思ったきっかけから教えてください。 志倉　それには大前提として、僕が“ひねくれ者”であることをお伝えする必要があります。 ――そんなところから（笑）。 志倉　とにかく僕は否定から入るクセがあって、リアリティーのない物語に感情移入ができないんです。物語のリアリティーとは科学的であることだと僕は思っていて、これはもう絶対に揺るがないんですよ。たとえば本来、ロボットものだったら根拠や理屈より、エンタメとして楽しめればいい世界設定のものが多いですよね。でも僕は、巨大ロボットが倒れたら、

ホーム / ハック / 【Bash】コマンドの終了ステータスを判定して何かしたい時のイディオム

インフラのボトルネックを理解する コードはもちろん、リリースしてから安定して動かせるように面倒を見るまでが仕事というのが、弊社の開発スタイルなので、そこで最近学んだことについて、文献や自分の実体験からボトルネックに関する考え方をまとめてみた。 CPUボトルネック CPU使用率に対する基本的な考え CPU使用率が80％から90%をずっと推移している！と聞くと、自分のPCの感覚だと、「やばそう」という感覚に陥りますが、インフラにおいての使用率はそうとも限りません。 CPU使用率高い: うまくリソースを使い切っている CPU使用率低い: オーバースペック ただ、高いCPU使用率にも許容出来る度合いがあったりもするので、そこらへんの判断軸などを踏まえて、まとめてみる。 現実世界の例 CPU使用率が高い状態というのは、実世界に置き換えると、店員がみな忙しく働いているという状態です。利用者からすればオ

こんばんは、夜中たわしです。 今回は主にはてなブロガー向けの記事です。 前回の記事のためにLINE風の表現ができるCSSを作ったんですが、それのやり方が知りたいという熱い声（1件）があったので、公開することにしました。 他のサービスでも使用可能ですが、はてなブログ向けの導入方法として紹介します。 紹介するCSSでできること できないこと 制作背景・前置き 注意事項 CSSにコードを追加（その1） CSSにコードを追加（その2） 会話形式CSSを導入している場合 使用方法 おわりに 紹介するCSSでできること これから紹介するCSSでできる表現はこんな感じです なるほど しいたけ　しいたけ そのしいたけの人は一体？ わかりません なんか料理が出てきた このようにLINEのグループ会話、に近い表現ができます。 補足：このしいたけは私が撮影したものです 一応、画像じゃないですよ。テキスト部分など

コンテナ技術入門 - 仮想化との違いを知り、要素技術を触って学ぼう コンテナ技術を適切に活用するには、コンテナが「どうやって」動いているかを学びたいところ。はてなのエンジニアhayajo_77さんがコンテナの要素技術の勘所を解説します。 こんにちは。株式会社はてなでサーバー監視サービス「Mackerel」のSREを務めるhayajo_77（ @hayajo ）です。 さて、コンテナ技術はDockerの登場がきっかけとなり、本格的に活用が始まりました。現在はKubernetesを始めとするコンテナオーケストレーションツールや AWS, GCP, Azure などのクラウドサービスで提供されるコンテナマネジメントサービスを採用したサービス運用事例が数多く紹介されており、コンテナ技術は「理解する」フェイズから「利用する」フェイズに移ってきています。 コンテナそのものは上記のツールやサービスにより

…

※続刊である14巻については「俺ガイル14巻の考察・感想【長文・ネタバレあり】」をご覧ください。 ※興味深いコメントをたくさん頂いておりますので、是非とも併せてご覧ください。ひとつひとつに返信はしていないのですが、きちんと読ませて頂いております。 ※『俺ガイル』アニメと原作の他の考察記事は「やはり俺の青春ラブコメはまちがっている。カテゴリ」にまとめてあります。ぜひとも併せてご覧ください。 比企谷八幡における考察なぜ比企谷はプロムを手伝いたいのか物語は前12巻からの続き、プロムの中止を平塚先生から聞かされて学校に走り戻るところから始まる。比企谷はプロムの開催に拘泥している。その理由は雪ノ下雪乃を「いつか、助けるって約束したから」（12巻、P353）である。13巻ではもう少し詳しく踏み込んで書かれている。 ここで関わることを諦めてしまえば、それは俺たちの過去の関係性を、奉仕部の在り方を否定する

jqはとても便利なコマンドです。 JSONを返すAPIを実装するときや、SaaSのAPIから特定の情報を抜き出してシェル変数に代入するときなど、web開発や運用には欠かせないツールとなっています。 しかし、私にとってjqのクエリを一発で書くのは容易ではなく、思い通りの出力が得られないことがよくありました。 難しいエラーメッセージに悩まされて、jqで書くのを諦めて別の言語で書き直すこともありました。 jqの十八番と思える場面で使いこなせないのは、なかなか悔しいものがあります。 ツールを使うのが難しいなら、同じものを作ってしまえばよいのです。 jqの全ての機能を実装する jqを言語としてきちんと書けるようになる jqを完全に理解する jqの全ての機能を自分で実装してしまえば、jqがどういうものか、クエリがどのように処理されるのか、詳しくなれるはずです。 jqを得意な言語と言えるようになって、ク

ラノベのタイトルみたいな記事を書く、という夢が叶いました。 github.com 開発に至った動機 以前から、アマチュアの小説はプロに比べると、描写不足な傾向があるのかもしれない、と思っていました。 特に不足がちだと感じるのは「時間」に関する描写です。 季節がわからなかったり、昼か夜か、平日か休日かみたいなことが不明瞭な作品が多い気がします。 しかし印象だけで語ってもアレなので、実際に差があるのかどうかを計測してみました。 計算式は、 時間描写の文の数 * 時間描写分布のエントロピー / 文の数 です。 「時間描写分布のエントロピー」というのは「全体を通じて、どれだけ満遍なく時間表現が書かれているか」という数字だと思ってください。 例えば時間描写が冒頭部にしかなかったりすると数値が小さくなり、全編を通じて満遍なく描写されていると、数値が大きくなります。 あと時間描写というのは、一応「季節、