NJSSの技術スタック大公開！〜なくてはならないサービスを目指して〜 ｜ 株式会社うるる

こんにちは！ NJSS 事業本部のエンジニアの栗原と申します。 私は2018年夏にうるるに入社してから現在に至るまで NJSS のサーバーサイドエンジニアとして、 Web 開発とインフラ構築を中心に従事しており、現在は複数ある開発チームのいちリーダーを務めております。 最近はありがたいことに面接やカジュアル面談の場面が増えてきており、候補者の方からたくさんご質問をいただきます。 その中でもよくいただくのが「どんなフレームワークを使用しているのか？」「どんなインフラで組んでいるのか？」の2つです（参画するプロダクトの構成はやっぱり気になりますよね！） そこで今回は2021年7月にリニューアルを実施した NJSS のインフラ構成をご紹介いたします！ NJSS（エヌジェス）は「入札情報速報サービス」の略で、あらゆる省庁・自治体が公示している入札情報の検索・閲覧とタスク管理がWebページ上で完結できるサービスです。 www.njss.info さまざまな機能を提供しておりますが、中でも NJSS が重要視しているポイントは以下の3点です。 各自治体・機関から上がってくる入札情報を早く、漏れなく登録できていること 累計約2,000万件（2022/8/3時点）の入札情報に対してユーザーがストレスなく検索できること 早朝に送る新着案件メール（速報メール）を遅延なく確実に配信できること NJSS のサービス提供をする上ではこれらを実現できるアーキテクチャである必要があります。 それでは本題...と言いたいところですが、本題を語る前にまずは NJSS の全体の流れと3つのドメインを理解する必要があります。 NJSS は Web クローラーとクラウドワーカーを活用して案件情報を収集し、閲覧しやすい形に情報を整理した上でユーザーにお届けしております。 つまり、入札情報を 「溜める為のサービス（ワーカードメイン）」と 「見せる為のサービス（ユーザードメイン）」の2つが存在し、アプリケーションもそれぞれが独立して稼働しております。これに 「検索機能を集約した中間ドメイン（検索ドメイン）」 を加えた計3つのドメインによって構成されております。 ※もともとは1つのモノリシックサービスだったのですが、リニューアルの際に分割を実施しました。なぜ分割したのかはこれだけで記事1本書けそうなのでそちらはまたの機会に！ ドメイン構成を踏まえ、いよいよ本題です。まずは全体の構成からどうぞ。 ほぼすべてをAWSで構築しており、できる限りフルマネージドなインフラ構成になるように構築しています。これによりインフラ監視工数を最小化し、 アプリケーションエンジニアが開発に集中できる環境を実現しております。 また、ローカル開発環境構築の容易性が高いのも特徴です。 基本的には docker-compose コマンド1発または yarn コマンドで必要な環境が立ち上がり半日もあれば環境構築が完了するので新規参画者もスムーズに開発に参画できます。 それでは各種詳細を見ていきましょう。 Amazon ECS (Fargate) API, Batch, QueueWorker などのサーバーサイドアプリケーションは一部を除き ECS Fargate で動作しております。これによりインフラ管理工数が最小限化できたことに加え、ローカルでも Docker を使用することで本番と同等の手順で開発・デバッグ可能なメリットを享受できております。 Amazon RDS (Aurora) データベースの永続化機構としてRDS Auroraを採用しております。死活監視に加え、データベース容量の上限管理もしなくていいのが魅力的です。これにより日常的な監視はCPU、Memory使用率、スロークエリなどに限定することができております。 Amazon ElastiCache (Redis) Cacheサーバーとして Redis を使用しております。Memcached との選択だったのですが、冗長構成が組める Redis を採用しました。(ただし色々あって現在は単一構成となっております。。。) Amazon SQS 非同期処理を扱う処理については特に複雑な処理を扱うケースがなかったことから、癖が少なくAWS上で完結できるSQSを採用しました。リニューアル後から SQS 起因での大きなトラブルは起きておらず、非常に安定して運用できております。 Amazon CloudFront ...

blog.uluru.biz