はてなブックマーク

概要 Firebase AuthenticationとGoogle Workspaceからのメール送信が必要なシステムで、SPFレコードを以下のように登録していた。 v=spf1 include:_spf.firebasemail.com include:_spf.google.com ~all mxtoolbox でSPFの構成をチェックしたところ、以下のような警告を発見。 Too many included lookups (11) Too many DNS Lookups? Solve this problem with SPF Flattening SPFにおけるDNSルックアップの最大回数は10回までという制限がある。 疑問 FirebaseはGoogleのサービスだからSPFのアドレスも重複しているのでは? 調査 redditにも同じような投稿があった。 It looks li

はじめに Googleが提唱するSREプラクティスの一つにトイルの削減 1 があります。トイル (toil) という言葉は日本語であまりなじみがありませんが、「苦労する・こつこつ働く」といった意味合いがあります。 SREにおけるトイルの定義は、原典とも言える書籍 SRE サイトリライアビリティエンジニアリング 内で次のように定義されています。 トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つものです。 本記事では、システム運用におけるトイルの定義を再確認し、トイルを削減する上での実践的なノウハウの一例を紹介します。 トイルの定義 SRE サイトリライアビリティエンジニアリング では、次の分類に1つ以上当てはまるような業務はトイルとなる性質が

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

金曜の夜に見たくないアラートが。 続いて複数プロダクトで強制シャットダウン祭り。 DatadogでAWSイベントを監視していたのでアラートは飛んできたけど、全てのイベントが通知されてないことに気付いた。8イベント中、最初と最後の2件しかきてない。 これよく考えたら当前で、障害自体は5時間近く続いた1イベントなので、障害中のイベントは一切飛んでこない。 中間イベントも送信したかったら監視モニターにある「automatically resolve...」なんちゃらのオプションを有効化しておけば良い。例えば1時間後にアラートを自働で閉じて、その後も障害が続く場合は続報も飛ばしてくれるようになる。 Terraformならこんな感じ。 resource "datadog_monitor" "aws_service_check" { name = "AWS service check" type =

課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可

概要 2020年10月15日、HashiCorpがWaypointという新しいプロダクトを発表しました。 Announcing HashiCorp Waypoint Waypoint Github - hashicorp/waypoint 簡単に説明すると、デプロイ設定ファイル1つ書くだけで、Amazon EC2やECS、Google Cloud Run、Azure Container Instancesといったクラウド環境にワンライナーでビルドからデプロイまで出来てしまう凄いツールです。 機能 Waypointは、AWSやGoogle、Azureといったプラットフォームにアプリケーションを構築・リリースするためのワークフローを提供する waypointup up コマンドで、アプリケーションのビルドからデプロイ・リリースまでを一括で実行することができる 現在サポートしているプラットフォー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 会社では週に数回、採用面接を担当してるのですが、最近ではフロントエンド・バックエンドだけでなくSREの採用も執り行うようになりました。 ここではSREを採用する際に実際に私が面接で質問する主な観点と趣旨について公開していこうと思います。 誰が書いてるか 現職は メタップス にて横断的なテックリードやSREエンジニアをしてます。学生の頃に「ユニバーサルHTML/XHTML」やヤコブ・ニールセンの「ウェブ・ユーザビリティ」に感化されフロントエンド技術に興味を持ち始め、その後バックエンドに携わるとミーハーらしくPoEAAやDDDにハマり

概要 AWSを始めとするパブリッククラウド環境でインフラ運用を始めると、サーバ構築からインフラ監視、セキュリティ対策、コスト管理まで考えなければならないことがたくさん出てきます。 ここではAWSを初めて運用するインフラエンジニア、SRE向けにスモールスタートな環境構築からスケーラビリティの高いインフラ構成まで、様々なノウハウを公開していこうと思います。 初めにやること アカウント設計 システムを運用する上で、本番環境以外に開発環境や検証環境を作成するケースは多いと思います。AWSでサービスを運用する場合は大まかに次のパターンに分かれることが多くなります。 1つのAWSアカウント、1つのVPC (ネットワーク) に全ての環境を構築 1つのAWSアカウント、VPCごとに環境を分けて構築 AWSアカウントを環境ごとに分けて作成 どのパターンが最適かは、システム構成や規模によって変わりますし、運用

概要 Terraformを使い始めて一年ほど経ったので、設計や運用上のノウハウを公開していこうと思います。 基本的にAWSを使うことが多いので、AWS寄りの話になります。 設計編 利用可能なプロバイダを調べる TerraformはAWSやGCPといったクラウドサービスをコード化できることで有名ですが、オフィシャルだけでも様々なプロバイダに対応しています。 私はAWSのほか、GitHubやDatadogをコード化して運用してます。 ネットワーク設計 サービスを構築する上で本番環境のほかに開発やステージング環境を作りますが、環境の分け方は大きく分けて次のいずれかになることが多いと思います。 1つのVPCに全ての環境を入れる 環境ごとにVPCを分ける 環境ごとにAWSアカウントを分ける 2のパターンで設計する場合、Terraformで構成を組む際はVPCをdevelopment、staging、

概要 ECS運用において、Dockerコンテナはデプロイの度に破棄・生成が繰り返されるため、アプリケーションが生成する各種ログはコンテナ内に保管しておくことができない。 すべてのログはイベントストリームとして扱い、外部ストレージに送る必要がある。 本ページではECSを運用していく中で発生したログの取り扱いに関する遍歴をまとめていく。 ※このページは、ECS運用のノウハウからログの取り扱いに関する項目を抜き出して再編集したものです。 Phase 1: CloudWatch Logsの導入 コンテナ運用を考慮したアプリケーション設計では、The Twelve Factor Appが参考となる。 この中のLogsセクションではログの取り扱いで以下の記述がある。 A twelve-factor* app never concerns itself with routing or storage o

概要 Private VPC(or サブネット)に配置したAPIサーバをAPI Gateway経由でインターネットに公開す方法を解説する。 APIサーバの設計 システム要件からAPIは次のように分類した。 公開API: インターネットに公開する必要のあるAPI 非公開API: インターネットに公開する必要のないAPI。Privateサブネットからのみアクセス可能 設計レベルで考慮したこと。 認証周りをCognitoで統一したい APIにキャッシュの仕組みを取り入れたい 仕様はOpen APIで書いてるので、Swaggerでバリデーションしたい 外部APIに関してはリクエスト制限を設けたい API AggregatorとしてはAWSが提供するAPI GatewayのほかKong等もあるが、今回は上記全てに対応でき、かつTerraformのリソースも揃っているAPI Gatewayを採用した。

概要 AWS ECSを運用するために内製で開発したデプロイツールを公開しました。 リポジトリ 何ができるのか Slack botに対し deploy と打つと、ECSクラスタに対象となるソースをデプロイします。またコマンドベースのデプロイやGitHubのPushをトリガーとした自動デプロイもサポートします。 機能詳細 サービスやタスクスケジューリングのデプロイ、タスク実行をサポート YAMLベースのタスク定義 環境変数に渡した秘匿値の暗号化・復号に対応 (KMS) デプロイ形式 Slackを用いた対話形式のデプロイ コマンドベースのデプロイ GitHubのPushをトリガーとした自動デプロイ デプロイ状況を可視化するWebコンソールの提供 デプロイコマンドが実行する処理 イメージのビルド イメージのプッシュ (ECR) タスクのデプロイ 図解。 Webコンソールはデプロイの状況を可視化しま

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 関連記事 マイクロサービスを支えるインフラアーキテクチャ (AWS Dev Day 2019登壇資料) ECSデプロイツールを公開しました ECSにおけるログの取り扱いを別ページに移動させました 設計 基本方針 基盤を設計する上で次のキーワードを意識した。 Immutable infrastructure 一度構築したサーバは設定の変更を行わない Infrastructure as Code インフラの構成をコードで管理 (Terraformを採用) Serverless architecture 無駄にサーバを増やさない アプリケーシ

※1: CLIからのみ実行可能 Beanstalkの特徴 環境構築が楽。EC2+RDSという一般的なアプリケーションであればBeanstalkコンソールでほぼ完結 コンテナを用いないアプリケーションも構築可能 Multi-container Dockerを利用すると、裏でECSが動く (ECSを意識しなくてもアプリケーションが動く) Beanstalkはとにかく環境構築が簡単。ウィザードに従ってうっかり Create environment なんて押すもんならいきなりインスタンス起動してアプリケーションが動き出す。間違えて3回くらい押した。 Beanstalkは環境構築が簡単な反面、裏で何のサービスが連動しているのか分かりにくい側面もあります。障害が発生した時、問題の切り分け (コンテナが原因なのか、ECSか、それともBeanstalkの問題か) が困難となる印象です。 ちなみにBeans

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Rails Container <- Here --------------------------------- Docker --------------------------------- Vagrant (CentOS) --------------------------------- VirtualBox --------------------------------- LocalMachine (OS X) 関連ページ DockerでMySQL+永続コンテナを構築する VagrantにCentOS 7.0をインストールする 前提となる環境 Host OS: Mac OS X VirtualBox 4.2.26 Vagrant 4.3.26 Guest OS: CentOS 7.1 Docker 1.5.0-dev Container OS: CentOS 7.1 MySQ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?