OpenWork Engineer Blog

OpenWork を運営するエンジニアによるテックブログです。

OpenWork の技術スタック

サーバーサイド

PHP (Symfony) web infra, Python web infra, Go infra, Bash infra, OpenAPI web

OpenWorkのサーバーサイドは主にはPHP x Symfonyで実装されています。 PythonをAWS Lambdaで使ったり、決済まわりをGoで開発したり、その時々で言語を選択しています。 スマホアプリの開発が進む中で、OpenAPIを使ってAPI仕様書を書くようになりました。

プロジェクトの構成に関しても、サービスの成長に伴うコードベースの増大に対応していくため、クリーンアーキテクチャやドメイン駆動設計を参考にしたものへの変更を進めています。

関連ブログ記事: API仕様書にOpenAPIを使用して感じた良さ

フロントエンド

JavaScript (Vue.js, jQuery) web, Babel web, webpack web, ESLint web, Prettier web

Vue.jsを使用し一部のページはSPAで開発しています。 古い機能はjQueryゴリゴリで実装されているので、チャンスがあればVue.jsやES2015+に置き換えていきたいと考えています。

ネイティブアプリ

Kotlin native, Retrofit2 native, moshi native, Data Binding native, RxKotlin native, Epoxy native Swift native, RxSwift native, RxCocoa native, Alamofire native MVVM native, Clean Archtecture native

OS標準のコンポーネントをできるだけ活用しつつ必要に応じてOSSライブラリを取り入れています。 MVVMにUserCaseやRepositoryなどクリーンアーキテクチャのプラクティスを取り入れ、保守性は高いが堅すぎない設計を心がけています。

プラットフォーム

Elastic Beanstalk infra, ECS infra, Cloud Run infra

主に Elastic Beanstalk を使ってサーバーを構築・管理しています。しかし Elastic Beanstalk では、プラットフォームのバージョンアップへ追従する必要がある、PaaS であるが故に自由度が制限されている部分があるなど、サービスの成長に伴い問題が生じているため、徐々にですがアプリケーションをコンテナ化して ECS に移行しています。 新規サービスの開発などで新たに構築するシステムに関しても ECS を選ぶことが多いですが、機械学習周りでは GCP の Cloud Run も採用しています。要件を最も満たすのは何かを都度検証した上で、技術選定することが重要です。

関連ブログ記事: Web サーバーの構成

Webサーバー

Apache infra, Nginx infra

Web サーバーの大半は Apache (2.4 系) で動いています。 一方、CDN の後段に置いている画像プロキシサーバーに関しては Nginx を採用しています。Nginx は静的コンテンツの配信に強く、 image_filter_module を使えば画像の加工も容易です。画像プロキシサーバーは、オリジンサーバーである S3 に置かれた画像を適宜リサイズ・キャッシュしており、画像加工の手間や S3 アクセスによるオーバーヘッドを抑えています。

データベース

Amazon Aurora(MySQL互換) webinfra, Elasticsearch webinfra, Redis webinfra, DynamoDB webinfra

データベースは基本的にフルマネージド型のサービスを選択するようにしています。 RDB に関してはパフォーマンスや可用性を考慮し Amazon Aurora を採用しています。 Elasticsearch は企業や求人の検索、スカウトの対象者検索機能など、検索関連機能で活用しており、 Redis は SQL のクエリキャッシュやログイン周りなどに利用し、ユーザーがストレスを感じないサイトの応答速度を実現しています。これらについても、自前で管理しなくてよい AWS の ElastiCache を利用しています。

CDN

Fastly infra, AWS CloudFront infra

画像の配信には Fastly を、一部静的アセットに AWS CloudFront をそれぞれ利用しています。

DWH

TreasureData webinfra, Google BigQuery infra

メインのデータウェアハウスとして TreasureData, サブ (アクセスログ用) として BigQuery を利用しています。
現状、TreasureData をデータレイク的にも利用してしまっており、システム負荷やデータ量の問題が顕在化してきているため、近々データ基盤を刷新する予定です。

ログ

Fluentd infra, logstash infra

アプリケーションのログは Fluentd 経由で S3 や TreasureData に送られます。 RDB から Elasticsearch へのデータ同期の一部で logstash を利用しています。

CI/CD

CircleCI web, AWS CodeBuild/CodePipeline infra, Bitrise native

CI/CD はプロジェクトやシステムによって異なります。 OpenWork のメインシステム (Web アプリ) のデプロイ (※) には CircleCI を利用しています (※: CI はステージングデプロイ時にフックして動くように仕込まれています)。また、一連のリリース作業を Slack 上から行えるように、現在リリースの自動 (ChatOps) 化を進めています。 サブシステムの CI/CD には AWS の CodeBuild と CodePipeline を利用することが多いです。

IaC

CloudFormation infra, Terraform infra

インフラのコード管理に CloudFormation と Terraform を利用しています。現状どちらかに一本化はされていませんが、使い勝手や将来性などをもとにして最適な方法を見つけられればと思っています。

監視

AWS CloudWatch infra

各インフラリソースの監視には CloudWatch を利用しています。また、CloudWatch Alarm で生じたアラートを Slack に通知しています。

Testing Tools

TestRail nativeweb

そもそもテストケースを残していく習慣がほぼなかった上に、 エクセル、スプレッドシートでのテストケース管理は、ノウハウを残すという意味でも 実用性に乏しいため、TestRailを導入しました。 まだまだ、TestRailに載せることができていないケースも多く、テストに関して言えば個人依存が強いのが現状です。

分析、可視化

Tableau 全員, Google Analytics 360 全員

データの分析、可視化ツールは、エンジニアに限らず利用可能です。 会社としても勘や経験に頼った意思決定ではなく、データを用いた意思決定を重視しています。 またデータから仮説を導き、それを元にした施策を打つだけでなく、 データを取得できるようにすること自体が開発案件になることもあります。

その他ツール

GitHub, Slack, Backlog