AWS CDK (Cloud Development Kit) を使用している案件において、CDK Pipelines による CI/CDパイプラインを実装しました。 公式ドキュメント がなかなか難解で概念を掴みづらく、また、チュートリアルどおりに作る程度では実運用に投入できるほどの仕上がりにはならないため、業務できっちり使えるレベルになるよう丁寧に設計してみました。

突然ですが、私は 女神転生シリーズ が大好きです。 (と言いつつ、一番好きなタイトルは女神転生ではなく 魔神転生II SPIRAL NEMESIS です。) いつでもどこでも仕事中でも女神転生を感じられるように、同シリーズに登場するミニゲーム「コードブレイカー」を TUI で再現してみました。

先日、Grafana Labs から Grafana Alloy という OpenTelemetryコレクタがリリースされました。 これは従来のコレクタ実装である Grafana Agent Flow の後継とされています。 (Alloy のリリースに伴い、Agent は Deprecated となりました。) 早速 Alloy を使って OpenTelemetry の シグナル である Traces、Metrics、Logs を収集してみました。

日夜 ITシステムの構築・運用に従事していると、稀に Linux の Liveイメージを使いたくなることがあります。 この記事では、Debian Live Project の成果物を用いて、独自にカスタマイズした Liveイメージを作成する手順を解説します。

検証作業で作成したクラウド・リソースを、たまに消し忘れてそのまま放置してしまうことはありませんか？ そんな場合にコストが微妙にかかり続けていることに気づきたいので、直近の請求分をチャート化して定期的に Slack へ投稿するボットを作りました。

弊社ではインシデント管理に PagerDuty と Opsgenie を併用しています。 PagerDuty を主系、Opsgenie を副系として運用しており、PagerDuty の Statusページ をサブスクライブして異常が発生した場合は Opsgenie に通知を飛ばすようにしています。 ところが最近、この Statusページが Atlassian の Statuspage から PagerDuty自身の同等サービス に移行されました。 この移行に伴い、以前に使用していた Opsgenie の Statuspageインテグレーション が使えなくなったため、挙動はそのままに新たな仕組みに切り替えました。

弊社の最近の傾向として、Kubernetesクラスタの運用をお任せいただく案件が多くなってきています。 このような案件においては、正式に受注する前の環境調査のために、まずはクラスタの参照権限のみ頂戴しています。 クラウド上にシステムを構築している場合、IAM (= Identity and Access Management) のメカニズムに基づいて権限を付与するのが一般的です。 近年ではマネージドの Kubernetesサービスを利用するシステムが増えてきていますが、IAM と Kubernetes の権限を結びつける仕組みは各クラウド・プロバイダによって少しずつ異なっており、適切な権限管理のためにはそれらの違いを正しく理解する必要があります。

弊社は MSP (Managed Service Provider) であるため、お客様のシステムの運用全般をまるっと委任していただく案件が頻繁に発生します。 このようなケースではスタッフを 1人ずつ委任元のアカウントに招待してもらう方法が一般的ですが、弊社のように多数のお客様と関わる組織ではメンバー管理の手間が問題になってきます。 この問題に対処するため、3大クラウド・プロバイダの AWS、GCP、Azure はいずれも包括的な組織間委任の仕組みを提供しています。 今回の記事では、その仕組みを活用した委任管理の堅牢化・効率化のベストプラクティスをご紹介します。

弊社ではオンコールとインシデントの管理に PagerDuty を利用しています。 弊社の監視システムにおいて、アラーティングについてはメールや Slackなどの多チャネルに同報しているものの、エスカレーション体制は PagerDuty に強く依存しています。 PagerDuty のダウンタイムや遅延は弊社の業務品質を直接的に低下させるため、そのリスクに備えて我々は PagerDuty をバックアップする仕組みを構築してきました。

先日、Ubuntu Server 20.04 の DNSサーバをデフォルトのものから変更したところ、あるタイミングで何者かが勝手に /etc/resolv.conf を書き換えて、変更を巻き戻してしまう事案が発生しました。 プラットフォームは IDCFクラウド です。 その調査結果と対策をご紹介します。

Nagios の CloudWatchプラグインを作ったのでご紹介します。 単純な実メトリクスの取得だけでなく、Metric Math や Metrics Insights もサポートしています。

CloudWatch で独自メトリクスを計測したい場合、CloudWatch API を直に扱ったり、CloudWatchエージェント の各連携機能を使うなど、いくつかの方式が考えられます。 この記事では、それらの各方式を比較し、それぞれの使い所を考察してみました。

とある案件で Prometheus のメトリクスを使って Kubernetes Pod をオートスケーリングさせる必要が生じたので、その実現方法を調べてみました。

前回の記事では、URL監視の始め方についてご紹介しました。 今回はもっと一般的なトピックとして、監視全般の設計の進め方について、実在のシステムを例に解説したいと思います。 クイックガードが運営している「ひとりインフラ」という Webサイトに対して、具体的にどのような判断で監視設計を行なったのか見ていきます。

Webサービスを立ち上げたら真っ先に導入したい監視項目の 1つに、URL監視が挙げられます。 URL監視とは、その名のとおり URL に対して監視リクエストを飛ばし、そのレスポンスの中身や応答時間を見てサービスの状態を判断する監視手法のことです。

ちょっとしたジョブを定期的なスケジュールで実行するには cron が便利でお手軽なのですが、それなりの規模になってくるとジョブ同士のオーケストレーションや安定した運用のために専用のジョブ管理システムが必須になってきます。

先日、ユーザ認証のバックエンドに Amazon Cognito を利用されているお客様システムの監視について、設計からお任せいただく機会がありました。 そのときの知見を基に、Cognito をどのように監視したらいいのか改めて整理してみました。

弊社ではお客様のメール環境の管理をお任せいただく案件も多く、送信ドメイン認証として必ず DKIM (DomainKeys Identified Mail) を設定するようにしています。 Amazon SES や SendGrid などのモダンなメール送信サービスでは、その仕組みを知らなくてもガイダンスにしたがってセットアップするだけで簡単に DKIM を有効化できます。

弊社では一部の監視システムに InfluxData の TICKスタック を使っています。 監視対象によってはメトリクス数が非常に多く、増大しがちな InfluxDB (= データ・ストア) の負担を抑えたいという課題がありました。 (真っ先に限界を迎えるのはいつだってバックエンドなので。) データ・ストアのオフロードのため、メトリクス・コレクタである Telegraf の側で値を取捨、加工し、少数の統計値に集約してから InfluxDB に送出する仕組みを検討したのでご紹介します。

ここ 1〜2年の傾向として、弊社でも Kubernetes を扱う案件が増えてきております。 設計から構築、運用まで一貫してお任せいただくことも多いのですが、安定運用するうえでオートスケールの活用は欠かせません。 (というか、これを活用しないと Kubernetes の価値は半減です。) ところが、Kubernetes にはオートスケールの仕組みが何種類もあり、さらにプラットフォーム独自のスケーリング方式も含めると、初見者にはなかなか全貌が把握しづらいところでございます。

システムの正常稼働に責任を持つエンジニアにとって、好むと好まざるとにかかわらずオンコール (緊急時の保守サポート体制) は馴染み深いものです。 特に我々 MSP (Managed Service Provider) は、お客様の代わりとなってオンコールを引き受ける保守サービスが主要な業務のひとつであり、複数のお客様に対して安定かつ持続的に 24時間365日のオンコール体制を維持するために日々研鑽を重ねております。

クラウドやコンテナの採用が当たり前となった現代では、Pets vs. Cattle (※) に例えられるように、インスタンスは使い捨ての Immutable かつ Volatile なものとして扱うことが多いと思います。 一方、そんな時代であっても、弊社では諸々の事情により 1台のベアメタル・サーバをペットのごとく大事に使い続ける案件は多く、そういった使い捨てできない環境下でも PHP のバージョン管理をやりやすくするために phpenv を活用しています。

先日、とある Ubuntuサーバの /etc/cron.d/配下に debパッケージのゴミ (= *.dpkg-old とか) がいくつも放置されていることに気がつきました。 このようなゴミは cron がよしなに無視してくれることを経験的には知っていたのですが、正確な仕様が気になってあらためて man をじっくり読んでみたところ、いろいろ興味深い発見 (というか罠) があったのでご紹介したいと思います。

以前の記事 (PagerDuty の通知ルールを自社の営業日カレンダーに基づいて制御する) で予告していたとおり、柔軟にカスタマイズ可能なルールに基づいて休業日を判定するコマンドライン・ツール Wholidisuka を公開しましたのでご紹介します。

誤って HSTS (HTTP Strict Transport Security) をすべてのサブドメインに対して有効化してしまったサイトについて、サーバ側から強制的にサブドメインのみ無効化する方法を調べてみました。

弊社ではオンコール/インシデント管理に PagerDuty を活用しています。 検知された障害は弊社が一次受けして調査、復旧を実施するご契約が多いのですが、中には、弊社スタッフだけでなくお客様にも直接 PagerDuty から障害通知を飛ばしてほしいというご依頼をいただくこともあります。

この QG Tech Blog は、はてなブログ などのブログ・サービスを使わずに自前で仕組みを構築、運用しています。 はてなブログの他にも Medium や note、WordPress.com など優れたサービスが数多ある中、なぜそれらを利用せずわざわざ自分たちで実装したのか、その背景や設計思想、アーキテクチャについてご紹介したいと思います。