peepの2019年を支えた技術

2019年が終わってしまうのでpeepの2019年を支えた技術を紹介します。

ついに2019年も終わりです。

2019年、peepは100万DLを突破し大きく成長した年でした。

そんなpeepの成長の裏には沢山の技術的な進化があったので、一部ですが紹介したいと思います。

エンジニアの数が2倍に増員

まずはなんといっても人です。peepの開発に関わっている人が2倍になりました！

エンジニア採用が難しいと言われているこのご時世にこれだけ人が増えたのは非常に嬉しいです！

2倍になったのですがまだまだ募集しているので、ブログを読んで少しでも面白そうと思った人は応募してください！もしくはtwitterで僕にDMください！ランチに駆けつけます！

iOSエンジニア、Railsエンジニア、UI/UXデザイナー、ディレクターを募集してます！(๑•̀ㅂ•́)و✧

（副業コミット歓迎ですよー！）

さて、本題の「peepの2019年を支えた技術」を紹介していきます！

アプリケーションサーバーをECS EC2モード → ECS Fargateモードに変更

最初はアプリケーションサーバーに関しての紹介です。

peepのインフラはAWSのECS EC2モードで動いていたのですが、ある理由からECS Fargateモードに変更しました。

EC2モードでは、設定したタスク数が起動しているEC2インスタンスに均等に配置されるようになっています。

EC2インスタンスだけを増やしても配置されるECSタスク数は自動的に増加したりはせず、元のECSタスク数を保ったままです。

ECSタスクが増えないということは中で動いているworkerの数も増えないので性能が上がったとは言いづらいです。

つまりEC2モードで最高のパフォーマンスを出せるEC2:ECSタスクの比率を保つためには同時にどちらも増やす必要があります。

この2つの調整を同時におこなうことも可能なのですが、対応コストや自由度を考えるとEC2インスタンスに依存してタスク数を増減させないといけないEC2モードよりも、Fargateモードにしたほうがいいという判断をしました。

Fargateモードの場合、EC2インスタンスの管理から開放されます。インフラ側はECS タスク1つにいくらのCPUリソースやメモリを割り当てるかを考えるだけで設定が完了し、そのタスクを何個動かすかということだけを調整すればよいのです。

現在はFargateモードで動いておりオートスケーリングも非常に安定して稼働出来ています。

画像配信サーバー変更（Cloudfront → Imgix）

当初はアプリに最適化されたサイズの画像を配信するためにAWS lamdaを使い画像をリサイズしてCDNにキャッシュする方針をとっていました。（よくある構成ですね。）

しかし現行のAWS Lambda内の処理では、リサイズされた画像の画質が少し劣化して配信されていました。

こちらもAWS Lambda内の処理をチューニングするという解決方法も会ったのですが、今後の拡張性や対応工数を考えた結果、画像配信専門のSaaSに任せることにしました。

SaaSの選定はCloudinaryとImgixで迷いましたが、Cloudinaryはストレージサービス+CDNという構成になっており、既存の画像配信システムから移行するためにはストレージごと移行する必要があります。

移行コストを考えるとシンプルにCDNだけを提供しているImgixのほうが低かったので今回はImgixを採用しました。

Imgixは流石専門SaaSという感じで、CloudFrontで配信していたときよりも約半分の容量で配信してくれています。

動画の配信サーバー変更（Cloudinary → CloudFront）

動画の配信に関してですが、先程もでてきた画像配信SaaSのCloudinaryを使っていました。

Cloudinaryは画像配信が得意なSaaSですが、動画の配信サービスとしても活用が可能です。しかも、画像と同じようにURLを修正するだけでリサイズ処理された動画を配信してくれます。

original: path/to/video.mp4
横幅480px: path/to/video.mp4?width=480 //正確には違いますがイメージです

かなり便利なのですが、画像配信が得意なSaaSだからなのか、動画に関しては細かい不具合などがあり、非常に困っていました。

また、料金面でもCloudinaryは従量課金制ではなく、ガウス関数的な料金体系で、各プランの最小の配信料でも、Max値の金額を支払う必要がありました。

上記2つの理由で今回は途中でCloudinaryを離れるという決断をしました。

デプロイ方法を手動からCI（Circle CI）に変更

こちらもあるあるなのですが、弊社ではデプロイが手動でおこなわれていました。masterブランチにマージされたら手動でdockerのimageを作成しECRにアップ、ECSタスクの値を書き換えてECSにデプロイといった感じです。

ミスが起きたことはないですが、流石にひたすらボタンをポチポチするのは手間になりますし、ヒューマンエラーも心配です。そこでCircle CIを導入し、PRがマージされたらstaging環境にデプロイ、Circle CI上でボタンを押すと本番までデプロイされるようにしました。

Heroku Review Appを使いGitHub PRごとに環境を作成した

弊社では複数人がクライアント側のアプリを開発し、また複数人がAPI側の開発を同時に行なっています。

しかし、弊社は開発環境が一つしか無くみんなでその環境を使っている状態でした。

このような開発体勢にしていると、自分が開発している部分ではないAPIがデプロイされてしまうと、開発できないアプリ開発者がでてきます。

今までは頑張ってブランチをマージして同時に開発できるようにしていたのですが、流石に気持ち悪さと限界が来て環境を分けようと決めました。

いろんな選択肢があったのですが、最小の工数でかつ、人に依存しないような形で今回の要望を満たせるものでHerokuのReview Appという機能を選択しました。

Review Appを使うとGitHubと連携して、Pull Requestの作成をトリガーとして自動的に環境を作ることが可能です。

この図のようにReview Appを使うと各環境で別ドメインが割り当てられ、アプリ開発者はドメインを変更するだけで別機能の開発が可能になりました。

こうすることでサーバー側もアプリ開発者側もなんのストレスもなくアプリの開発に集中できるようになりました。

データ分析基盤をGoogle BigQueryに統合

peepは分析に非常に力を入れています。ときには担当者は一日中クエリを書いていることもあります。

分析を始めたとき、最初に行なったのはDWHの作成です。

peepのデータはRDB一つで終わるような単純な構成ではなく、分析、マーケティングなどのデータも含めると複数のデータベースが存在していました。

しかし分析する際はすべてのデータベースの情報を横断的に見ていく必要があります。この場合、一つのDBに統一したほうが圧倒的に分析しやすくなるので統合DB（DWH）を作成しました。

DWH作成に関して、自前で実装するのは実装コスト、メンテナンスコストの観点から非効率なので外部のデータ転送支援SaaSである「trocco」を採用しました。

troccoを活用することで複数のデータリソースを一つに統合することができ、現在では多くの指標を用いた分析をおこなうことが出来ています。

peepは2019年多くの進化を遂げました

みなさんのおかげでpeepは非常に多くの進化を遂げることが出来ました。

2020年は今年の勢いを落とさず、更に角度をあげて成長していくつもりですのでよろしくお願いいたします。

We Are Hiring!

仲間を募集してます！

事業の成長期でやりたいことが沢山沢山あるのに仲間がまだまだ足りません！

ぜひご応募、ランチのお誘いお待ちしております！！！

peep一同より！