AWS Startup ブログ

Category: AWS CodeBuild

ビズリーチ様、ECS活用アーキテクチャー大刷新についてお伺いしました

こんにちは、Startup担当事業開発の畑 浩史です。 株式会社ビズリーチでキャリトレの開発をされている外山さん、中村さん、龐さんにAWS久下とシステム刷新についてお話をお伺いしました。 外山 英幸さん(写真右) キャリトレ事業部 プロダクト開発部  部長:キャリトレ事業部の部長としてプロダクトの企画、システム運用、保守、開発や新プロダクトのアーキテクチャーを見られています。2歳になられたばかりの息子さんがかわいくてかわいくて仕方ないとのこと。趣味はお子さんと遊ぶことと、夜にAWSの勉強をすることだそうです。座右の銘は「なんとかなる、なんとかする」。 中村 恵介さん(写真左から2番目) キャリトレ事業部 プロダクト開発部:新卒でビズリーチ社に入社し、現在はテックリードとして、アプリケーションレイヤー、インフラレイヤーともにご担当。趣味はスノーボード、ボルダリング、ゲーム、プログラミングとアウトドア、インドア両面でアクティブで、現在、独身で売り出し中とのことです!座右の銘は「千思万考」。 龐 冲さん(写真右から2番目) キャリトレ事業部 プロダクト開発部:中国 雲南省ご出身で2007年に来日され、現在はインフラのトップとしてAWSの構築や運用をされています。日本語が堪能で、社内Slackでは「日本人以上に日本語が上手い」と評判だそうです。趣味はクラシックギター。座右の銘は「一期一会」。 キャリトレとはどのようなビジネスでしょうか? 20代の方向けの転職サイトで、第二新卒の方など、初めての転職の方を中心にご利用いただいております。2014年に正式ローンチし、ビズリーチの新たな事業の柱として、現在は多くの求職者の方や企業の方にご登録いただいております。今年は5月にCMも開始し、より多くのユーザーの方々に価値を提供できるサービスを目指しています。 現在、プロダクトが抱える課題は何でしょうか? サービスが短期間で急成長したため、スピード優先で矢継ぎ早にシステムを増改築してきた結果、どうしてもその場しのぎであったり、いびつな対応となった部分ができてしまいました。結果、所謂スパゲッティコード、機能間密結合となり、問題の特定が難しいことや、影響範囲が大きくなります。また、インフラ面も全てをコードで管理しているわけではないため、実際に動いているものを見てみないと分からないことや、問題発生時の調査が難しいこと、見直しが難しいといった状況があります。 課題に対して、どのような対応をされていますか? 5年経つこのタイミングで、アーキテクチャーの刷新を現在進めています。大きな方針として、 1. スケールしやすい 2. 工数を削減する(作らなくてよいものはなるべく作らない) 3. 運用負荷が軽い の3点を常に意識しています。 また、刷新の際に他クラウドの利用も検討しましたが、これまでの経験の蓄積、権限管理、監査対応、Auroraのパフォーマンス等の観点から、既存と同様にAWSで再構築することに決めました。その際に、AWSのトレンド、王道を最大限に活用して構築していくことも方針の1つとしました。 それ以外に、Dockerコンテナ技術を使うという全社方針があったため、キャリトレもそれに沿った開発をすることにしました。その際の選択肢としてKubernetes on EC2がありましたが、Kubernetes は機能的に充実している面はあるものの、折角AWSを利用しているのに自分たちで管理することが増えすぎる点、またKubernetes をアプリエンジニアに覚えてもらう必要がある点、他のAWSのサービスとの連携による恩恵を受けられない等から、運用のしやすさを考え選択しませんでした。EKSは東京リージョンのローンチがまだなので、見送りました。結果、ECSで再構築を進めています。Fargateは構成自体を自動化して運用コストを下げるために有効なため、検証を続けています。 具体的な再構築の内容を教えていただけますでしょうか? これまで、Jenkinsでビルドしていたものを、AWS CodeBuild、CodeDeploy、CodePipelineを使って全て構築するようにしています。並列でいくつか動かしてもスケールできるように、Jenkinsを管理しないことでできるだけ運用負荷を下げることを目指しています。これまでテストに時間がかかったり、タスクを増やすと落ちたりしていたことが無くなることを期待しています。 次に認証周りについて、インフラだけではなくアプリも見直しています。ログインに関する機能をAmazon Cognitoを使うことで自前で作らないようにすることや、API GW利用によりエンドポイントの認証をSTSで行うことやロールベースのアクセスコントロールなどで工数削減に繋げています。 DBは、MySQL5.6 RDSから Auroraへ移行し、移行コストがかからず楽に移行できています。Auroraに移行することで、Slaveに対しての遅延が少なくなり、Read系の考慮点も減らすことができ、可用性の面でのメリットが大きいです。また、カラム追加のロックがかからないことやリードレプリカアクセスにロードバランサー機能があることも運用負荷軽減となります。検索については、EC2 Solrの構成でしたが、保守コストがかかっていたため、運用コスト優先でElasticsearchを選択し、専用のサーバーを立てることを減らしています。ログ周りはfluentdでエージェントを立ててEC2のサーバーを立てていましたが、CloudWatch Logs Agent-> Kinesis -> Lambda -> S3で再構築し、Athena、EMR、Glacer 、Datadogの利用を考えています。バッチはAWS Step Functionsを活用します。 今後のチャレンジは? キャリトレが大きくなるとマイクロサービス化が必要になると考えていますので、サービスを増やした時の共通基盤の作成は今後の課題です。また、将来的にはサーバレスな構成も考えていきたいです。 今回のre:Inventの新機能発表で注目は何でしたか? […]

Read More