【フォースタ テックブログ】SREエンジニアとして入って一ヶ月でやったこととこれからやりたいこと

最近焼酎の美味しさに目覚めた、テックラボSREチームの @tossy_yukky です。
フォースタートアップス（以下フォースタ）初のSREポジションとして、今年の6月にジョインしました。
経歴としては、SES > Web広告系企業でインフラ周りをやりつつ新規サービス立ち上げを何個か > マッチングサービスやECサービスでなんでも屋さん、からのフォースタジョインとなります。

今回は、半沢直樹でも「SREチーム呼んで！」で話題になった、SREという立場・業務内容の紹介をすると同時に、社内での立ち位置も明確にしておこうという、一石二鳥を狙っていきます。

SREとは

『SRE サイトリライアビリティエンジニアリング ――Googleの信頼性を支えるエンジニアリングチーム』
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy　編、澤田 武男、関根 達夫、細川 一茂、矢吹 大輔　監訳、Sky株式会社 玉川 竜司　訳
https://www.oreilly.co.jp/books/9784873117911/

まずはここからです。
昨今では知名度も高いので、これがSite Reliability Engineering（サイト信頼性エンジニアリング）の略であることを知っている方も多いのではないでしょうか。
そしてこれは同時にSite Reliability Engineerの略でもあります。

それではサイト信頼性とはどういうことでしょう。

ITサービスは、サーバやネットワークなどのインフラ部分があり、サービスで使う＆貯めるデータがあり、その上で動くアプリケーションがあります。
それらのどれかに問題があれば、ユーザにとっては満足にサービスを利用することができないでしょう。

そうならないための全てのことを行うのがSRE、というわけです。

一般的に SRE＝インフラ担当 のように思われている節があるのも事実ですが、有名なSRE本によれば、SREチームの50％ほどはソフトウェアエンジニアであり、SRE業務のうちでも50％は開発業務である、とあります。
機能開発そのものではないですが、バグの改修からログ出力、アラートの仕組み、CI / CD、パフォーマンスチューニングまで、とても単なるインフラ担当とは言えないほどの業務範囲です。

加えて、サービスにはそれを作る人・運用する人もいます。
その人達の組織がうまく回っていなければ、サイト（サービス）の信頼性を損なうことにもつながりかねません。
つまり、開発・運用組織というシステムに対する設計 / 実装 / 運用も、SREの業務には含まれていると言えます。

まとめると、SREとは「サービスを利用することができる状態を維持し続けるために必要な全てのシステムを理想的な状態に持っていく」仕事、ということになります。

フォースタでのSRE

それを踏まえて、フォースタでの具体的なSRE業務を挙げてみましょう。

フォースタには、社内で利用されるタレントエージェンシー支援システム（SFA/CRM）と、社外に向けた国内の成長産業領域に特化した情報プラットフォーム「STARTUP DB」の2つのサービスがあり、それぞれに開発チームがいます。
どちらのチームもサーバサイドエンジニア、フロントエンドエンジニア、デザイナーなど含め4〜6名ほどの規模です。

ただインフラに関してはCTOの戸村（@KenjiTomura）が中心となり、色々な人が都度対応という形で、
メイン業務としてインフラだけを担当する人はいませんでした。
なので、実際問題として現在、フォースタでのSREのメイン業務はインフラ周りということにはなります（いきなり前節で言っていたことをひっくり返すようですが）。

そしてエンジニア組織として。
フォースタはスタートアップ企業に対して支援を行っていますが、フォースタ自身も上場こそしているものの、母体であるウィルグループから分社して4年程、まだまだ組織として成熟しているとは言えないのが現状です。
エンジニアの人数も、正社員だけで言えばCTOを含めて6人。
組織というシステムに対して、制度、仕組み、文化、どれもこれから醸成していく必要があります。

ジョインしてからやったこと

ここでは、私がフォースタにジョインしてからおよそ2ヶ月の間にやってきたことを並べてみます。

Infrastructure as Code

まずはインフラっぽいところ。
フォースタではサービスが大きく2つあるというのを前述しましたが、開発自体はマイクロサービス化が進んできており、管理すべきリソースはもっと多いです。
なので、それらを全てコンソールから管理するのも辛いということで、Terraformを用いたInfrastructure as Code(以下、IaC)化を進めました。
既にいくらかはTerraformのコード化されているリソースもあり、Github / Circle CI / Terraform Cloudを連携させてplanコマンドの出力をブラウザ上で確認できるような仕組みはできていました。その基盤に対して、まだコード化されていないリソースをひたすらimportしていくという作業になります。

Terraform公式のimportだけでは作業量がとんでもないことになっていたので、最初はOSSのterraforming( https://github.com/dtan4/terraforming )を使おうとしていたんですが、これも対象となるリソースの種類が足りず、GoogleのOSSであるterraformer( https://github.com/GoogleCloudPlatform/terraformer )を利用して作業を進めました。
ただ、これもtfstateがTerraform Cloudにある場合が考慮されていなかったため、TypeScriptでterraformerでのimport > ファイル整理しつつterraform importまでを行うツールを自作しています。

監視・アラート

SREの業務を行うに辺り、指針となるSLI（Service Level Indicator）、SLO（Service Level Objective）を設定する必要があります。
これはそのサイト（サービス）がユーザに対して「どの程度使われているか」「どの程度満足に使ってもらえているか」を見るもので、SLIは何を軸として見るか、SLOはそれがどれくらいの値であればいいのか、を示しています。

以前はインフラリソース単位でのメトリクス（CPU使用率、メモリ使用率、ディスク使用率、Load Averageなど）は取得していたものの、それぞれがユーザに対してどういった影響が出ているのかわかりにくいため、SRE本を参考に新たな指標を作ってみました。

ツールとしては、フォースタでは基本的にインフラは全てAWSで構築していることもあり、一旦Amazon CloudWatch上のダッシュボードを使います。単純に他の監視サービスを別に使うよりは料金も安く、取得期間も長いという理由です。
指標としては、Golden Signalsと呼ばれるメトリクスがそれに当たります。これはレイテンシ / エラー(5xx数） / トラフィック / サチュレーションの4つなんですが、サチュレーションに関しては一旦外しています。理由としては、サチュレーションの対象となるリソースを選定するのがまだ難しかったというのがあります。
一方でアラートに関してもそのGolden Signalsを基に見直しを行いました。
夜中に起こされる理由として、CPU使用率が90％であることではなく、500エラーが大量に起こっているという方が納得感もありますし、より緊急度が高いはずだからです。

ポストモーテム

こちらもSRE本からになりますが、インシデントが起こった際、その振り返りを行うためにポストモーテムを導入しました。
単なる障害報告と言ってしまえばそうかもしれませんが、ポストモーテムの価値は、これを使って開発者全員が認識を合わせること、他のチームの障害だからで済ませず自分事として捉えられるようにすることだと思っています。

具体的な内容で言うと、報告書のフォーマット、インシデントの報告基準、報告書のレビューを行うにあたっての仕組み作り、がそれに当たります。

この辺りは、エンジニアというよりは半分マネジメントに近いものがある気がします。

ドキュメンテーション

全てにおいてそうだと思うんですが、決まったことや決めたいことに対してドキュメントを残しておくのは重要だと思っています。なのでこれらSRE業務についても、社内で利用している情報共有ツールで書くことから始めていきました。

これはプラクティスとか技術力とかではなく、組織としての文化だと思うので、今後も絶やさずに醸成したいと考えています。

目指す先

信頼性のあるサイト（サービス）を維持するのはもちろんなんですが、それを維持できる文化、組織を作っていきたいと思います。

そこに向かって全メンバーが走りやすい環境を整えるため、日夜励んでいきます！

【フォースタ テックブログ】簡単に認証機能を実装できるAuth0を導入してコア機能開発に集中できた話

こんにちは。テックラボの佐々木です。主にバックエンドを担当しています。

フォースタートアップスは社外に公開している「STARTUP DB」の他にも複数のWebサービスを運用しています。ほぼ全てのサービスで認証機能を実装していますが、いくつかのサービスでは「Auth0」と呼ばれる認証機能構築のためのSaaSを利用しています。

この記事ではAuth0についてあまり知らない人向けに、Auth0を使って実現できることと弊社における実際の利用例を紹介します。

Auth0とは

Auth0は認証のトータルソリューションを提供するSaaSで、言語やフレームワークを問わずWebサービスやネイティブアプリに認証・認可の機能を実装できます。簡単なログイン認証機能であれば既存のアプリケーションに数行のコードを追加するだけで実装できます。

利用してみて感じたAuth0のメリットは以下の3つです。

複数サービスで同じ認証基盤を利用できる

言語やフレームワークによらないため、使い方を理解すれば他の言語・フレームワークを利用したサービスにも容易に横展開することができます。例えばフォースタートアップスではRubyで書かれたWebサービスで初めてAuth0を利用したのですが、そのタイミングで概念や使い方を理解できていたので、その後PythonやNode.jsを利用したサービスへの導入も素早く行えました。

また、Auth0はシングルサインオンや二段階認証といった認証に関わる様々な機能を実現できます。そのため機能ごとに別のライブラリやSaaSを利用する必要はなく、運用するサービス全てでAuth0を利用していれば、認証関連にかかる学習・実装コストを大幅に削ることができます。

素早く容易に実装ができる

単純なログイン認証機能であればAuth0のWebコンソールでの設定と、アプリケーションへの数行のコード追加だけで実装できます。

例えばJavaScriptだと以下のコード追加のみです。

document
 .getElementById('login')
 .addEventListener('click', async () => {
   await auth0.loginWithRedirect();
 });

Auth0: Secure access for everyone. But not just anyone.
https://auth0.com/jp/

その他にもGoogleやFacebookなどのソーシャルアカウント認証を利用するかどうかの設定や、アクセスコントロールの条件もWebコンソール上でできるため、コードに修正を加えることなく素早く直感的に実装ができます。実際にパスワード認証からGoogleアカウント認証への変更作業も、1分とかからずに対応できました。

認証関連の機能を容易に実装できるため、エンジニアはサービスのコア機能の開発に集中することができます。

多くの機能を無料で利用できる

Auth0は月間7000アクティブユーザーまでは多くの機能を無料で利用することができます。コンシューマー向けのサービスであれば無料で使うのは難しいかもしれませんが、エンタープライズ向けのサービスであれば初めのうちは十分に補える数だと思います。

認証は実装が難しい割にはユーザーにとって価値が見えづらい機能なので、MVPの段階ではAuth0を利用し、マネタイズできそうということがわかってからAuth0に課金するか別の方法で認証を実装するかを検討しても良いかもしれません。

Auth0を使って実現できること

具体的な利用例を紹介する前にAuth0で実現できることを紹介します。

ユニバーサルログイン

ユニバーサルログインとはセキュアなログイン認証画面を実現するための仕組みです。

ユニバーサルログインを利用するとログイン時にAuth0ドメインのログイン画面にリダイレクトされます。ログインと認証が同じドメインで行われドメイン間で認証情報が移動しないため、セキュリティが向上しフィッシング攻撃や中間者攻撃を防ぐことができます。

また、ログイン画面のUI/UXがデフォルトで用意されているため、UI/UXを一から構築する必要はありません。ユニバーサルログイン用に若干のコード追加は必要ですが、一度追加してしまえばその後はWebコンソールからログインページの多少のUI/UXを変更することができます。

M2M認証

アプリケーションから呼ばれるパブリックなAPIを作る際には、そのAPIに認証の仕組みを持たせる必要があることが多いです。

アプリケーションからリクエストを受けてAPIの認証トークンをアプリケーションに返す認証サーバーとしてAuth0を利用でき、セキュアなAPIを作成することができます。

以下の図の1、2のフローがM2M認証です。

機器間（M2M）認証を使用する
https://auth0.com/blog/jp-using-m2m-authorization/

シングルサインオン

シングルサインオンによってログインの回数が減るためUXの向上が期待できるだけでなく、ユーザーのパスワード管理の負担を減らすことでセキュリティリスクを削減できます。

フェデレーション方式でシングルサインオンを実現しており、未ログインのサービスへのログイン時にAuth0が提供するシングルサインオンサーバーにリダイレクトさせてCookie情報をチェックすることで、サービスの認証をすることなくログインできます。

How to Implement Single Sign On
https://auth0.com/learn/how-to-implement-single-sign-on/

自前のサービス同士のシングルサインオン連携だけでなく、Zoom、Slack、Office365等の17のサービス(2020/07/29時点)とも連携させることが可能です。

二段階認証

二段階認証の追加やどのような認証方式を利用するかの切り替えもWebコンソールから容易に実施できます。

認証方式はいずれも認証コードを入力するタイプで、SMS、メール、もしくはGoogle Authenticator等を利用したワンタイムパスワードを選択することができます。

不正ログイン検知

ブルートフォースアタックの検知、ブロック、通知をすることができます。

また、Auth0は漏洩済みのログイン情報を保持しており、それらのログイン情報を使用したログインについても検知、ブロック、通知することができます。

ユーザー管理

誰がいつログインしたかを確認することができ、ユーザーのブロックや削除等も行うことができます。

また、ユーザーに自前のロールを割り当て、アプリケーション側でそのロールを利用した認可を実施することが可能です。

パスワードレス認証

パスワード認証だけでなくGoogleやFacebookなどのソーシャルアカウント認証にも対応しています。2020/07/29時点では以下のようなメジャーなソーシャルアカウント認証を含めた34種類のサービスに対応しています。

認証時追加処理

認証処理の際にコールバック処理として、以下のようなアクセスコントロールやWebhook等を実行します。

• メールアドレスのドメインが指定したものと異なる場合にはログイン失敗させる
• 指定したIPアドレスのホワイトリストと異なるIPアドレスからのログインの場合にはログイン失敗させる
• ログインしたユーザーの情報をSlackに通知する

フォースタートアップスでのAuth0の利用シーン

フォースタートアップスでのAuth0の利用シーンとして、ユニバーサルログインを利用したログイン機能とM2M認証を利用したAPI認証の実装方法や留意点を紹介します。

ユニバーサルログインを利用したログイン機能

自社用に運用している採用管理ツールへのログイン機能、データ分析ツールとして利用しているKibanaへのログイン機能を実装するためにユニバーサルログインを利用しています。

採用管理ツールのログイン画面は以下のようになっています。フォースタートアップスドメインのGoogleアカウント認証のみを許可しているため、ログイン画面としては見た目は物足りないですが驚くほど簡単に実装できます。

実装の流れとしては以下の通りです。紛らわしいのですがAuth0にはApplicationという概念があり、OAuthクライアントのことを表します。以下に出てくるApplicationとは作成した採用管理ツールのことではなくAuth0のApplicationという概念のことです。

1. Auth0のWebコンソールにてApplicationを作成する
2. 上記のApplicationに、ログイン処理後に遷移する採用管理ツールのコールバックURLを設定する
3. ログイン認証を付与する採用管理ツール側に、Auth0ログインページへの遷移処理とログイン後の処理を追加する

細かい手順については以下の通りです。この例はRuby on Railsの例ですが、選択した言語やフレームワークに応じた実装方法が丁寧に記述されています。

auth0.com

Auth0導入の前はRuby on Railsの認証ライブラリ「devise」を利用してログイン認証を行なっていました。

deviseには「current_user」「authenticate_user!」といった便利なヘルパーメソッドがあります。これらのメソッドをアプリケーション側でそのまま利用するために以下のモジュールを作成することで、既存コードへの影響を最小限にすることができました。

module Auth0Helper
 private

 def user_signed_in?
   session[:userinfo].present?
 end

 def authenticate_user!
   if user_signed_in?
     @current_user = User.from_omniauth(session[:userinfo]) # from_omniauthはuserを特定するロジック
   else
     redirect_to login_path
   end
 end

 def current_user
   @current_user
 end
end

M2M認証を利用したAPI認証

フォースタートアップスでは、Googleドライブ上のPDFをテキストに変換する処理を、AWSのAPI GatewayとLambdaを利用して構築しています。

PDFをパースする処理をAWS Lambdaで実装し、そのLambdaを呼び出すためのAPI GatewayのオーソライザーとしてAuth0を利用しています。

実装の流れとしては以下の通りです。

1. Auth0のWebコンソールにてAPI(と呼ばれるAuth0認証するためのエンドポイント)を作成する。このAPIを利用することで、認証トークン(クライアントIDとクライアントシークレット)を利用してAuth0で認証可能となる
2. クライアント側にて認証トークン取得処理とPDFパースAPIを呼び出す処理を記述する
3. AWS Lambdaの呼び出し元としてAPI Gatewayを用意し、APIのオーソライザーとしてAuth0を指定する

細かい手順については以下の通りです。

auth0.com

利用するAmazon API Gatewayの種類として「金額は安いが機能が制限されるHTTP API」「金額は高くなるが高機能のREST API」の2つの選択肢がありましたが、Auth0がJWT オーソライザーに対応していたため特に制限を意識することなくHTTP APIを利用することができました。

現在動いている新規事業においてもこのAPI認証の仕組みを利用していますが、類似のアーキテクチャーで認証機能を実装できているため短時間で開発が進んでいます。

おわりに

Auth0を使って実現できることとフォースタートアップスにおける実際の利用例を紹介しました。

認証に関する様々な機能を容易に実装できることがAuth0の優れた点で、認証という技術的に難易度が高い処理をAuth0に任せることでエンジニアはサービスのコア機能の開発に集中できます。

活用しきれていない機能がまだまだあるので、今後も知見を溜めて社内外に情報共有できればと思います。

【フォースタ テックブログ】ビジョンドリブンなエンジニア組織が"Spotifyモデル"を参考にこれからのチームについて考えた話

こんにちは、村林（@bayashimura）です。5月からフォースタートアップス にジョインした新参者です。前職ではSIerで社内向けアジャイルコーチをやっていました。

今日は私からフォースタートアップスの組織の話をさせていただきます。

現在のエンジニア組織体制について

フォースタートアップスでは「for Startups」というビジョンのもと、成長産業支援事業を推進するために現在積極採用中で、エンジニアの数も拡大中です。今後この流れはますます加速していく予定です。

フォースタートアップスにはテックラボというクリエイティブチームがあります。
このテックラボが私も所属するプロダクトを作るチームです。

今は大きく2つのチーム、スタートアップの魅力を世に発信するSTARTUP DBチームとタレントエージェンシー支援システム（SFA/CRM）チームに分かれています（それとは独立してSREの人やデザインの人もいたり）。
両チームともスクラムをベースにしたアジャイル開発を採用しており、各々でレトロスペクティブなどのイベントを行っています。

人数の増加につれ、テックラボ内のイベントも徐々に形が変わっています。

例えば週に一回のテックラボ内ミーティングでは、各々のチームが開発状況などを共有していました。しかし、もっと良いやり方をということで、月に一回のビジネスサイドの人間もいる場でお互いのプロダクトを紹介する場に変わりました。

他にもチーム同士の交流は週に一度、個人が発表してそれを聞く勉強会、みんなで技術に関して時間をとり調査して話しあうスキルアップ会を行っています。

これらのイベントを通じて、チーム間のコラボレーションが図られるようにしています。
実際に最近、タレントエージェンシー支援システムチームの佐々木が作ったアーキテクチャを勉強会で発表し、それを聞いた竹内（@manbo34）が再利用してかなり低コストに新機能を作りました。

ただし、このやり方でコミュニケーションコストの高さに疲弊せず交流を図れるのも、１０人前後の今の規模感だけだと思っています。
そこで、もう少し人が増えてきたら試してみたいのはSpotifyモデルです。

Spotifyモデルとは

大規模アジャイル開発手法のひとつです。
音楽配信サービスで有名なSpotifyが2012年に発表した働き方を模したものです。

3つの都市にまたがって、30以上のチームがひとつのプロダクトをアジャイルで開発しているSpotifyでは、従業員同士のコラボレーションとコミュニケーションコストの低減という、二つの相反する目的をどちらも追及するために複雑な組織構成になっています。

簡単に説明すると、Spotifyモデルでは機能毎に区切られた小さな分隊、分隊の集まりの部隊、フロントエンド、サーバサイドなどのレイヤ毎の集まりである支部、社内コミュニティのようなギルドが存在します。

Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds - Crisp's Blog
https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify

詳しくは以下の記事が参考になります。

Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む | 『リーン開発の現場』越境せよ！
https://lean-trenches.com/scaling-agile-at-spotify-ja/

ただし、このような記事も出ているようにSpotifyは2020年現在、この形態では働いてないみたいです。

Spotifyは 'Spotifyモデル 'を使っていない - アジャイルよろず相談室 - Quora
https://jp.quora.com/q/agile/Spotify%E3%81%AF-Spotify%E3%83%A2%E3%83%87%E3%83%AB-%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84

上記の記事で言及されている通り、サイロ化された組織で働くと人は個別最適に走る傾向があります。

例えば大規模アジャイル開発の手法の一つであるLeSSでは「多くの大規模なプロダクト開発グループでは、（自分たち個々の部品、タスク、専門領域ではなく、）プロダクト全体へ全員が焦点を当てるように仕向けることが、スクラムをスケーリングするに当たって最も難しい課題の一つになります」と言及しています。

プロダクト全体思考 - Large Scale Scrum (LeSS)
https://less.works/jp/less/principles/whole-product-focus

テックラボはSpotifyモデルを参考にしつつ組織作りをしていきます

それでは何故、Spotifyに所属していた人間が失敗と言及したモデルを参考にするのでしょうか。

私たちはビジョンドリブンの組織です。ビジョンに共感できる人のみを採用してます。
スタートアップのためになっているかどうかが判断基準であること、それがチーム全員の共通意識になっていることがうちのチームの強みです。

また私たちの特色として、エンジニアが要件を細部にわたり考えます。

タレントエージェンシー支援システムチームに関しては、明確にプロダクトオーナーを置いておらず、どういう機能が必要かをエンジニアが細部まで考え、実際に使うヒューマンキャピタリストへのユーザインタビューもエンジニアが直接行います。

社内のSlackでは現在の会社の状況を表す様々な数字が行き交い、そこにエンジニアがアクセスし、現在必要な機能を分析しています。

CTOの戸村（@KenjiTomura）の「自由や権限を与えることで働く人間はクリエイティビティを発揮することができる。しかし良い判断をするためには判断するための材料を持っていなければならない。そのために全メンバーが数字とか状況を理解する必要がある」という思想に基づいてます。

このように、Spotifyが乗り越えられなかったサイロ化にも、全員のビジョンが合致し全体の情報にアクセスできる集団でなら立ち向かえるかもとの期待があります。

拡大していく組織でビジョンに共感しつつ、良い組織を作っていきたい人募集中です！

【フォースタ テックブログ】「STARTUP DB」サービスの紹介と使用技術・構成について裏側を公開します

はじめに

フォースタートアップスで「STARTUP DB」（スタートアップデータベース）の開発を担当している竹内 強（@manbo34）です。

「STARTUP DB」は、成長産業領域に特化した情報プラットフォームとして、「未来を牽引する国内スタートアップとエコシステムビルダーが出会い、産業をブーストさせること」をミッションに掲げ、2018年5月にサービスができました。

日本のスタートアップエコシステムは海外と比較すると、まだまだ活性化されておらず、情報が散在しているという課題があります。「STARTUP DB」は日本のスタートアップ情報を集約・可視化することを起点に、日本のスタートアップエコシステム、産業をブーストさせるべく日々開発を進めています。

今回はこの「STARTUP DB」のシステム構成について説明させていただきます！

STARTUP DB（スタートアップデータベース）とは

国内最大級の成長産業領域に特化した情報プラットフォームです。

「STARTUP DB」は、12,000社を越える日本のベンチャー・スタートアップ企業の情報を保有するとともに、起業家・投資家、エコシステムビルダーの方々累計100名以上のインタビューコンテンツをリリースしています。

2019年6月24日に、英語版をリリース。また、2019年7月には世界最大級のベンチャー企業データベース「Crunchbase」とデータ連携、日本のベンチャー・スタートアップ企業の情報を海外のプロフェッショナルに届けることで、国内の成長産業市場の発展に貢献しています。

【STARTUP DBとは？】ここ1年で大飛躍！！STARTUP DBの取り組みについてまとめてみました。
https://www.wantedly.com/companies/forstartups/post_articles/223849

2周年記念インフォグラフィック「HISTORY of STARTUP DB 」
https://media.startup-db.com/summary/startupdb-2nd-anniversary

STARTUP DBの構成

「STARTUP DB」は次のサービスで構成されています。

1. STARTUP DB
2. STARTUP DB MEDIA
3. 企業情報データベース

構成図

インフラにはAWSを利用しています。構成としては一般的ですが、DBとしてRDS（Aurora MySQL）があり、WebサーバはEC2、レスポンスのキャッシュにはElastiCache（Redis）、アセットはS3からCloudFront経由で配信、ドメイン管理にはRoute53を利用しています。

データ集計などにはLambdaを利用し、アプリケーションの保護にはWAFも使っています。LambdaはSTARTUP DBで使用しているスクリプトの定期バッチ処理にも利用しています。

単一障害点の排除と可用性を考え、可能な限り冗長構成を組んでいます。リクエストはロードバランサーにより分けられ、DBはMulti-AZ配置をとっています。過去、実際にDBのシステム障害が発生しましたが、自動フェイルオーバーの恩恵を受けて難を逃れたことがあります。

上記に加えてSendGrid、Zapierなどの外部サービスも利用しています。

各サービスの紹介と使用技術・構成について

１．STARTUP DB

https://startup-db.com/

「STARTUP DB」のトップページです。フロントエンドはVue.js、バックエンドはRuby on Railsを利用しています。主要な企業情報は、別途社内で管理している企業情報データベースからREST APIを利用して取得し、公開しています。このREST APIは内部DNSでアクセスしているため、外部からはデータを取得できないようになっています。

また、後述のSTARTUP DB MEDIAからも公開された記事情報をリアルタイムに取得し、企業に関連付けて表示するなどデータ連携しています。

会員登録（無料）をすると、お気に入りの企業をフォローでき、メールにて企業情報やイベント情報が届きます。会員様へのメールの送信はSendGridを利用しています。SendGridはクラウドベースのメール配信サービスで、API経由で配信できるため、メールマガジンのような一括メール送信などの運用コスト削減に役立っています。

STARTUP DBが掲載する企業情報は執筆時点で12,000社を超えており、スタートアップ企業データベースとしては国内最大規模となります。

掲載している情報量も膨大なため、時に不正なBotによるクロールを受けることがあります。利用規約でも、過度なアクセスにより負荷をかける行為などは禁止させていただいておりますが、不正なリクエストについてはWAFを利用してブロックするような運用をしています。

今後の展望として現在、フロントエンドとバックエンドが同じサーバーで動作していますが、マイクロサービス化を推進していることもあり、フロントエンドとバックエンドの役割を明確化し、物理的にも分けていきたいと考えています。

技術スタック

２．STARTUP DB MEDIA

https://media.startup-db.com/

STARTUP DB MEDIAは、「for Challenge」をテーマとして設定し、成長産業領域での起業やスタートアップへの興味を促し、読者の新しいチャレンジを後押しする、STARTUP DB編集部が運用するメディアです。起業家やベンチャーキャピタリストへのインタビュー記事、編集部が独自分析した記事を配信しています。

記事の配信にはWordPressを利用していて、特別な運用はそれほどしていないですが、体裁の変更や機能追加など柔軟に対応できるようテーマのバージョン管理を行っています。

今後はSTARTUP DBとの企業情報の連携にも、より一層の柔軟さが求められるため、WordPressから脱してHeadless CMS＋SPAへの転換なども検討しています。

技術スタック

３．企業情報データベース

「STARTUP DB」で取り扱うほぼ全てのデータを格納しているデータベースです。STARTUP DBの核となる企業情報や関連する情報を管理していて、専任スタッフが専用の管理画面から最新の企業情報を日々更新しています。

また、社内向けのタレントエージェンシー支援システム（SFA/CRM）にも企業データを提供するためにAPIを内部公開しています。

言語、フレームワークとしてはRuby on Railsを利用しており、フロントエンドもRuby on RailsのSSRとなっています。将来的にSPAにすることを検討しています。

現在、社内ではマイクロサービス化プロジェクトが進行しており、企業情報データベースも以前は社内向けSFA/CRMと同じリポジトリで開発していましたが、今は別リポジトリで管理・開発を行っています。今後もマイクロサービス化は進めていき、管理画面やAPIサーバーもそれぞれ分離していきたいと考えています。

技術スタック

おわりに

文中に何度も登場していますが「STARTUP DB」ではマイクロサービス化を進めており、フロントエンドとサーバーサイドの役割の明確化を図っています。

未来を牽引する国内スタートアップと個人・企業などのエコシステムビルダーを繋ぐHUBになるべく（壮大なチャレンジが待っています）、スタートアップ企業の魅力を伝えるサービスの担い手として、フロントエンド・サーバーサイドどちらも仲間を募集しています。

是非カジュアルにお話しませんか？

今までのご経験から培った能力・専門性によって、フォースタートアップスを次のステージに導いてくださる方のご連絡をお待ちしています。