こんにちはSREチームの宮後(@miya10kei)です。最近、テレビ📺からプロジェクター📽️に乗り換えて大満足しています🤗 みなさんのサービスでは送受信したメールの検索はどうしてますか？ サービスを運用していると「メールが届いてない」という問い合わせを受けることはあるあるではないかと思います。今回は送受信したメールを永続化し、検索できるようにした仕組みを紹介します。 背景 Park Directでは日々多くのメールを送受信しており、業務上メールはとても重要な要素になっています。また、システムにも貸主様と借主様がメールのやり取りをする機能があるため、メールが届いていない、UIに表示されないなどの問い合わせが一定の頻度で発生しています。その問い合わせはサクセスチームだけで調査が完結せず、サクセスチームから依頼された開発チームで調査が行われています。そのため、メールの送受信状況をサクセス

こんにちはSREチームの宮後(@miya10kei)です。最近、スマートホーム化にハマっていていろいろと買い漁っています🛒 N+1問題を検知するのって結構大変ですよね？ 今回はDatadogを使ってN+1問題を可視化し、パフォーマンス改善につなげた話を紹介したいと思います。 ※ 2024/05/29に開催されたJapan Datadog User Group Meetup#4 でもLTしてきました🎤 speakerdeck.com N+1問題とは？ N+1問題は主にデータベースへのクエリーを扱う際に出くわすパフォーマンス上の問題です。1つのクエリーでN件のデータを取得した後にそれぞれのデータに対して追加でクエリーが発行されることでパフォーマンスを大幅に低下させます。（1 + N問題と呼んだ方がしっくりくる気がしますが...🤫） 背景 この取り組みを始めた経緯は、システムへのリクエスト

はじめに SREの大木 ( @2357gi )です。最近美味しいお茶漬けを探しています。 今回は非同期タスクの処理を行うECS Serviceのオートスケーリングをいい感じにした話です。 非同期タスクが大量に積まれた際に、それを実行するworkerを柔軟にスケールアウトさせたいですよね。ただ、スケールインする際に処理中のタスクどうするの？中断されちゃったりしない？みたいな課題があると思います。 そこに対して、ECS Task Protectionを使用することによりいい感じにすることができたので紹介したいと思います。 関連技術はだいたい以下の通りです。 Django Celery ECS Service Auto Scaling (ECS Service) 背景 Park DirectのバックエンドはAPIを提供するbackend-api(Django)と非同期タスクの処理をおこなうwor

こんにちはSREチームの宮後(@miya10kei)です。最近、トリュフナッツにハマりビール🍺の消費量が増えています。 AWS CLIを使用する時にaws-vaultは使っていますか？ AWSのユーザ管理をAWS IAM Identity Centerに移行した際にaws-vaultの設定でつまずいたので解決方法を紹介したいと思います。 AWS IAM Identity Centerとは？ 複数の AWSアカウントやアプリケーションへのワークフォースのアクセスを一元管理するためのサービスです。外部IDプロバイダーと接続しSSO（シングルサインオン）連携をすることができます。ニーリーではGoogle Workspaceと連携させGoogleアカウントでログインできるようにしています。 aws-vaultとは？ aws-vaultはAWS CLIを使用する際の認証情報を安全に保存し、アクセス

はじめに SREチームの大木( @2357gi )です。 ECS Serviceのオートスケーリングやバッチなど、ECS Taskの起動停止が頻繁に行われる環境でAWS Configを有効にしていると、AWS Configのコストが無邪気に跳ね上がってしまうことがあります。 インターネット上では特定のリソースを対象外にすることによりコストを抑える手法が多くの記事として見かけますが、対象外にするとAWS Config側で「リソースタイムラインの表示」ができなくなったり、Security hubで使用する情報の記録を行うことができなくなってしまいます。 そこで、特定のリソースを「記録から除外」するのではなく、「日時記録に設定」することにより前述した懸念点を解消しつつ、コスト削減をすることができたので紹介します。 経緯 我々のプロダクトでもサービスのスケールや機能拡大に伴い AWS Config

はじめに SREチームの大木です。スノボの季節がもう終わりかけており、さみしい限りです。 feature staging環境*( 以下 feature環境 )自体のライフサイクルや管理をどうするか問題、なかなかどこも苦労していると思いますが、その中で今回それなりにいい感じの回答を出せたと思うので共有したいと思います。 *呼び方はpre-staging環境、pull request環境、テスト環境などいろいろありそうですが、私たちはfeature環境と呼んでいます。 どこが「いい感じ」なのかというと、PRのラベル付与によって環境の生成/削除を制御できる点です。PR画面上で楽々とfeature環境の管理ができたり、PR一覧からどのブランチでfeature環境が立っているかが分かりやすくなります。 feature環境について feature環境を当社のプロダクトであるPark Directの開発

こんにちは、株式会社ニーリーでプラットフォームグループのマネージャーをしている菊地(@_tinoji)です。 この度、ニーリーでテックブログを始めることにしました。記念すべき1本目の記事ということで、今後の投稿のハードルを下げるという大義名分のもと、テックブログを始めるまでの思い出話でも書いてみようと思います。 ニーリーって？ いきなり知らない会社の昔話を始められるのもアレだと思うので、簡単に会社の紹介をさせてください。 ニーリーは2013年に創業され、インキュベーション事業を始め様々な事業を展開したのち、2019年にPark Direct(パークダイレクト)という月極駐車場SaaSをローンチします。これが今の我々の主力プロダクトになっています。 賃貸住宅を検索できるようなサービスと似たUIですが、「契約までオンラインで完結」できるというのが推しポイントです。通常2週間程度かかると言われて