はてなブックマーク

Terraform 1.5 で追加された import ブロックと -generate-config-out フラグを組み合わせると、既存のパイプラインの中で安全にインポート作業が行えるようになります。 Hashicorp ではこのことを "config-driven import" と呼んでいます。 Terraform 1.5 brings config-driven import and checks これまでは terraform import コマンドでリソースを 1 つずつインポートし、それを定義する HCL も自分で書く必要がありました。コマンドを実行すると即座に tfstate に反映されるので、HCL がマージされるまでの間にほかの人が誤ってリソースを削除してしまう危険性がありました。そのため、チームで共同作業するリポジトリでは気軽にインポートできませんでした。 Terra

我が家のインターネット回線は NURO 光の 2 ギガプランを使っています。混雑時間帯でも速度低下は見られず、有線だと 1 Gbps 前後のスピードが出ています。 しかし、Wi-Fi でビデオ会議などの高トラフィックの通信を行うと、レイテンシーが悪化し通信が途切れることがありました。ひどいときには 1 日に何度も発生しリモートワークにも支障が出るような状況だったので、腰を据えてちゃんと調べることにしました。 トラブルシューティングしていくと、おおよその傾向が掴めてきました。 Wi-Fi 接続している台数が 10 台を超えると不安定になりやすい ビデオ会議などの高トラフィックの通信を行うと顕著に起きる リビングで Fire TV を使って動画を見ているとさらに悪化する ONU を再起動すると一時的に安定する NURO 光は ONU と Wi-Fi ルーターが一緒になっている この時点で ON

7 月末をもって freee 株式会社を退職します。先週金曜日が最終勤務日でした。 2016 年 5 月に入社したので 6 年 3 か月在籍したことになります。 在籍期間中は社内外問わず多くの方にお世話になりました。この場を借りて退職のことをお伝えする方もいるので、感謝の気持ちを込めて退職エントリーを書こうと思います。 TL;DR 2022 年 7 月末で freee 株式会社を退職します ネガティブな理由の転職ではありません。今でも freee のことは大好きです 8 月から SaaS のスタートアップで Software Engineer として働きます freee での思い出 freee では 6 年間 SRE として働いてきました。自分が入社した当時はまだ Auto Scaling も設定されていませんでしたが、それでも何とかやっていける規模感でした。今では当時と比べものにならない

Terraform で ElastiCache for Redis を定義するには少しコツが必要です。社内で間違った定義がコピペされていたので、忘れないようにポイントをまとめておきます。目新しい内容ではなく、ほとんどは公式ドキュメントにちゃんと載っています。 Terraform で ElastiCache for Redis (cluster mode disabled) を定義するには aws_elasticache_cluster と aws_elasticache_replication_group の 2 つのリソースがあります。 基本的には aws_elasticache_replication_group を使えば良いです。 Multi-AZ で可用性を高めるなら number_cache_clusters を 2 以上にして automatic_failover_enable

例年どおり、クリスマスに Ruby 2.7.0 がリリースされましたね。さっそく macOS 上に ruby-build でインストールしてみたのですが、明らかにいつもより時間がかかることに気がつきました。そのときは急いでいたので深掘りしませんでしたが、改めて調べてみると ruby-build が Homebrew の openssl に依存しなくなり、インストールのたびに openssl をコンパイルしているからでした。 Don't look for Homebrew openssl by gfguthrie · Pull Request #1375 · rbenv/ruby-build ruby-build: remove dependency on openssl by gfguthrie · Pull Request #46637 · Homebrew/homebrew-core

freee では仮想マシンのインフラ監視に Mackerel を使っていますが、Kubernetes を使っているところは前例にとらわれずゼロベースで見直そうとしています。現状は Elastic Stack と Mackerel のハイブリット構成になっています。 Elastic Stack による Kubernetes モニタリングシステムの紹介 - freee Developers Blog どの SaaS を使うかを決める前に、そもそも Kubernetes の何を監視すればいいのか？ というところから考え直しています。宣言的なマニフェストにより Kubernetes が自律的にあるべき状態を保ってくれるのであれば、これまでの監視とは異なってくるはずです。 監視の観点として、ここでは通知レベルを用いて次の 3 つに分類します。 None: メトリクスは収集するが通知しない Notic

CloudFormation で 3 AZ (Availability Zone) のサブネットを作るときに Fn::GetAZs でハマったのでメモしておきます。 利用できる AZ はアカウントによって違いがあるので、AZ をハードコーディングしてしまうと汎用性がなくなってしまいます。そのために用意されている関数が Fn::GetAZs で、指定されたリージョンの AZ を配列で返してくれます。 Fn::GetAZs で ap-northeast-1d が返ってこない ap-northeast-1a, 1c, 1d が使えるアカウントで次のような CloudFormation テンプレートを書くと、なぜか "Template error: Fn::Select cannot select nonexistent value at index 2" というエラーになりました。配列に 2 つ

CloudWatch Logs Insights を使って MySQL の performance_schema を分析する freee のプロダクトは RDBMS に MySQL を使っています。これまでもさまざまな方法でパフォーマンス改善を行ってきましたが、新たに CloudWatch Logs Insights を使って MySQL の performance_schema を分析する仕組みを作りました。 具体的には CloudWatch Dashboard を使って問題のありそうなクエリを見える化しました。次のスクリーンショットは一例ですが、このリストは CloudWatch Logs Insights にクエリを投げた結果です。 当初は DWH 用の Redshift に取り込んで Redash で分析するつもりでしたが、CloudWatch Logs Insights を使うこ

AWS re:Invent 2018 に参加してから、英会話をマスターするためにいろいろ試行錯誤しています。 読み書きはそこそこできる反面、リスニングがとても苦手です。リスニングが苦手なので、相手の話していることが理解できず会話が続きません。日本人の典型的なパターンではないでしょうか？ これは日常生活の中で英語を耳にする機会がほとんどないのが原因だと思います。 re:Invent に参加したときも、後半になるにつれて耳が慣れてきて聞き取れるワードが増えました。 というわけで、意識的に英語をリスニングすれば良さそうです。エンジニアという職業柄、日常的に英語のドキュメントや GitHub のコメントは読んでいるので、これを Text-to-Speech で読み上げさせることにしました。一度理解した内容であればリスニングしやすいというメリットもあります。 Text-to-Speech のサービス

Docker Engine 18.09 から Build-time secrets という機能が使えるようになりました。この機能を使えば docker build するときに secrets (API key, credentials, etc) を安全に取り扱えるようになります。 Introducing Docker Engine 18.09 - Docker Blog Integrate secrets in your Dockerfile and pass them along in a safe way. These secrets do not end up stored in the final image nor are they included in the build cache calculations to avoid anyone from using the c

この記事は 裏 freee developers Advent Calendar 2018 の 2 日目です。 タイトルにもあるとおり、11/26 - 11/30 までラスベガスで開催された AWS re:Invent 2018 に参加してきました。この記事はまさに帰国途中の空港から書いています。 re:Invent は初めて参加しましたが、とても充実した時間を過ごせました！ また re:Invent に参加して自分の中で大きな変化がありました。当初は Advent Calendar に参加レポートを書くつもりだったのですが、今回はその変化について書いてみようと思います。 AWS との出会い 自分が初めて AWS を触ったときは、まだ東京リージョンもなく、サービスの数も両手で数えられました。はっきり覚えていませんが、アカウントを作ったのは 2010 年の後半だったと思います。その後、JAW

先日、ステージング環境の K8s クラスタに一切接続できなくなる障害が起きました。調査してみると K8s クラスタの TLS 証明書が失効していたことが原因でした。 ドキュメントにもある通り、kubelet は Kubernetes API の認証に TLS 証明書を使っており、その有効期限はデフォルトで 1 年です。有効期限が 1 年というのは、今回の障害ではじめて知りました。 Certificate Rotation - Kubernetes The kubelet uses certificates for authenticating to the Kubernetes API. By default, these certificates are issued with one year expiration so that they do not need to be rene

今年の 7 月から freee の SRE チームのプレイングマネージャーになりました。先月 9 月まではメンバー 3 人、今月からはメンバー 5 人のチームです。社内では独自のロール名が付いていますが、世間一般に通じるロールだとプレイングマネージャーが一番近いと思います。 もともとプレイングマネージャーという仕事に興味はありませんでしたが、マネージャーとの 1 on 1 でやってもらえないかと打診されたのがきっかけです。迷ったときは「昨日の自分だったら選択しないことをあえて選択する」ことをモットーにしているので受けてみることにしました。 プレイングマネージャーに求められるのはチームのアウトプットを最大化すること、そしてチームメンバーの成長をサポートしつつ良いチームを作っていくことです。かつ、自分自身もプレイヤーとして OKR にコミットします（マネージャー業に時間を取られるので貢献できる

EC2 向けの Minimal Ubuntu を検証する機会があったので、ついでに Minimal Ubuntu の Docker イメージがどういう Dockerfile から作られているか調べてみました。 Docker Hub に登録されているオフィシャルのイメージは、すでに Minimal Ubuntu に変更されています。 Minimal Ubuntu, on public clouds and Docker Hub 今回調べてみてわかったのですが、Dockerfile の中では Minimal Ubuntu 向けに特別なことはしていません。 Ubuntu 18.04 の Dockerfile 今回は bionic-20180821 のタグで取得できる Ubuntu 18.04 の Dockerfile を調べました。 2018/08/29 時点の latest で参照される Do

MySQL の AUTO_INCREMENT 属性を使っている場合、整数型の上限に達しないか注意する必要があります。たとえば INT 型だと約 21 億 4700 万、unsigned が指定されていると倍の約 42 億 9400 万が上限です。 MySQL :: MySQL 5.7 Reference Manual :: 11.2.1 Integer Types (Exact Value) - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT 上限に達する前により大きな型にマイグレーションしなければなりませんが、そのためには上限まであとどれくらいかを調べる必要があります。各テーブルで LAST_INSERT_ID() を叩けば最後に生成された AUTO_INCREMENT の値を取得できますが、すべてのテーブルを網羅的に調べる必要がある

Amazon ES で運用しているログ検索基盤の Elasticsearch が高負荷状態に陥ってしまい、なんとかして安定させる必要がありました。具体的には CPU 使用率がほぼ 100% に張り付いてしまい、クライアントが接続できないという状況です。いろいろ試行錯誤してノウハウが得られたのでまとめておきます。 Elasticsearch のバージョンは 6.2.3 で、このクラスターの特徴は次のとおりです。 Fluentd からさまざまなログを集めて Kibana で検索する 日次でインデックスが作られ、古いインデックスは Curator で削除している Fluentd から Amazon ES へ直接送っていて、クライアント側のサーバ台数はそこそこ多い VPC の中に起動しているので Kinesis Data Firehose は使えない ちなみに、Amazon ES 前提の内容になっ

Amazon Elasticsearch Service (Amazon ES) では、クラスタを変更したときに Blue/Green デプロイが行われます（Amazon ES ではクラスタのことをドメインと呼びます）。 公式ドキュメントでは次のように説明されています。 Amazon ES では、ドメインの更新時に Blue/Green デプロイプロセスが使用されます。 Blue/Green は通常、2 つの本稼働環境（ライブとアイドル）に使用して、ソフトウェアの変更時に両者間で切り替える方法を指します。 Amazon ES の場合は、ドメインの更新用に新しい環境を作成し、これらの更新の完了後に新しい環境にユーザーをルーティングする方法を指します。この方法では、新しい環境へのデプロイに失敗しても、ダウンタイムを最小限に抑えることができ、元の環境を維持することができます。 本番環境で採用する

少し前に Twitter にこんなことを書きました。 エンジニアの給料は技術で世の中に貢献して感謝された結果だと思っているので、個人的には年収の上昇率を KPI にしています。世の中の役に立っていれば、あとから結果は付いてくるはず。 — Manabu Sakai (@manabusakai) May 22, 2018 このことについて若手のエンジニアと話す機会があったので、せっかくなのでもう少し詳しく書いてみようと思います。 感謝が先、お金はその結果 数年前から年収の上昇率を KPI とした目標を毎年立てています。年収なので会社からの給与所得に限りません。自分の場合は個人事業で技術アドバイザーもやっているので事業所得も含みます。 過去には「10 年間の投資でもっともリターンが大きかったのは自分への投資」という記事も書きました。 なぜこんな目標を立てているのか？ それは年収という目に見えるお

Kubernetes にコンテナをデプロイするのは manifest ファイルを kubectl apply で適用するだけなので、Capistrano や Fabric に比べればとてもシンプルです。ですが、データベースのマイグレーションまで自動化しようとすると途端に難しくなります。 今回は Kubernetes の Job でマイグレーションを実行する方法をご紹介します。他にもっといい方法があれば、ぜひ教えてください！ Kubernetes の公式サイト「Jobs - Run to Completion」から引用します。 A job creates one or more pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the

Symantec が発行した SSL/TLS サーバ証明書が Chrome や Firefox で段階的にサポートされなくなります。もう間もなく最初の期限を迎えるので、改めて自分たちのサービスで使っていないか再チェックしました。 Google Developers Japan: Chrome が Symantec の証明書に対する信頼を破棄する予定について Distrust of Symantec TLS Certificates - Mozilla Security Blog Chrome 66 以降、Symantec によって 2016 年 6 月 1 日より前に発行された証明書に対する信頼が破棄されます。現時点では、Chrome 66 は Chrome ベータ版ユーザーに対して 2018 年 3 月 15 日に、安定版ユーザーに対して 2018 年 4 月 17 日頃にリリースされる

3/10 (土) に開催された JAWS DAYS 2018 に登壇させていただきました。「AWS のマネージドサービスを使ったセキュリティ強化のための自動化」というテーマで、freee で取り組んでいる実例をご紹介しました。 Fintech / HRtech の SaaS プロダクトを少人数の SRE で支えるために行なっているセキュリティ強化のための自動化をご紹介します。具体的には AWS WAF や GuardDuty を活用して、攻撃の検知や防御、異変に気付くための工夫を詳しく取り上げます。 同じ時間帯に AWS の荒木さんのセッションがあったのであまり集まらないかなと思っていたら、満員御礼で立ち見が出るほどの大盛況ぶりでした。セキュリティへの関心の高さを感じるとともに、身の引き締まる思いで出番を待っていました。 JAWS DAYS 2018 の発表が無事に終わってホッとしてます。

Kubernetes を本格的に使っていくにあたり Kubernetes の裏側の仕組みを勉強しています。抽象化が進みブラックボックスになっているものを何となくの知識で運用するのは怖いからです。仕組みをちゃんと理解しているかどうかは障害時にはっきりと現れます。 というわけで、Kubernetes で意図的に障害を起こしたらどうなるのか試してみました。今回は特殊な Node 障害を想定して、Kubernetes のネットワークで重要な役割を担っている iptables のルールがすべて消えたという想定です。 なお、この検証で使った Dockerfile や Kubernetes の Manifest ファイルは GitHub で公開しています。 Docker イメージも Docker Hub の Public リポジトリにあるので、Kubernetes クラスタさえあればすぐに試すことができ

この投稿は社内の Qiita:Team に書いた記事を加筆・修正したものです。 「まずは当たり前のことをやってから言え」 この言葉は前職でお世話になった先輩の言葉です。障害が起きたときに最後の砦と信頼されていたエンジニアの方です。 いま思うとこの言葉が自分のエンジニア人生をより良くしてくれました。 「信頼されるエンジニア = 技術力が高いエンジニア」とは限らない 以前は「信頼されるエンジニア = 技術力が高いエンジニア」だと思っていましたが、実際にはそうとは限りません（技術力が高いエンジニアを批判する意図はありません）。 社内で周りを見渡せば納得すると思いますが、多くの人から信頼を得ているエンジニアはこんな人ではありませんか？ 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い

データ可視化ツールの Metabase が話題になっていたので、Redash との比較を兼ねて試してみました。 OSS のデータ可視化ツール「Metabase」が超使いやすい macOS の場合はローカル版が用意されているので、Redash よりも簡単に始めることができました。今回の記事でもこのローカル版で検証しています。 Metabase for Mac 国債金利の CSV データ 今回は手頃なデータとして、財務省が公開している国債金利の推移を可視化してみます。 1974 年からの日時データで約 11,000 件あります。元データとなる CSV ファイルは財務省のサイトからダウンロードできます。 国債金利情報 CSV の生データは扱いにくい和暦表記になっているので、Google スプレッドシートで和暦から西暦に変換しました。また、データが多いとグラフのレンダリングが遅くなるので今回は 3

Amazon Linux 向けに書いた Ansible Playbook を Amazon Linux 2 に対応させようと思ったのですが、facts を見ても区別できる要素がありません。必要なところだけ抜き出すとこんな感じです。 # Amazon Linux "ansible_distribution": "Amazon", "ansible_distribution_major_version": "NA", "ansible_distribution_release": "NA", "ansible_distribution_version": "2017.09", # Amazon Linux 2 "ansible_distribution": "Amazon", "ansible_distribution_major_version": "NA", "ansible_distri