[レポート]【パーソルキャリア様ご登壇事例】Amazon ECSを活用した、転職サービス「MIIDAS」のAWS移行事例 #AWSSummit

AWS Summit Tokyo 2018で講演された『【パーソルキャリア様ご登壇事例】Amazon ECSを活用した、転職サービス「MIIDAS」のAWS移行事例』のセッションレポートです。本セッションでは、16万人以上が利用する転職サービス「MIIDAS」を、パブリッククラウド上の仮想マシン群からAWSへ移行し、Amazon ECSとAmazon Auroraなどのマネージドサービスを組み合わせて、可用性・可変性が高まるように再編成された際、設計・構築・移行・運用の各段階において『なぜそうしたか』、『どのように解決したか』が、事例をもとに紹介されています。

AWS Summit Tokyo 2018

#Amazon ECS

#イベントレポート

#イベント

#レポート

#AWS

きうち

2018.06.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、きうちです。

2018年5月30日（水）～2018年6月1日（金）の3日間にわたり、品川にて開催されました『AWS Summit Tokyo 2018』。

こちらで講演されたセッション『【パーソルキャリア様ご登壇事例】Amazon ECSを活用した、転職サービス「MIIDAS」のAWS移行事例』を聴講しましたのでレポートします。

セッション概要

スピーカー

パーソルキャリア株式会社エンジニア
吉元裕人氏

概要

16 万人以上が利用する転職サービス「 MIIDAS 」を、パブリッククラウド上の仮想マシン群から AWS へ移行し、Amazon ECS と Amazon Aurora などのマネージドサービスを組み合わせて、可用性・可変性が高まるように再編成しました。設計・構築・移行・運用の各段階において『なぜそうしたか』『どのように解決したか』、事例をもとにご紹介します。セッション一覧 - AWS Summit Tokyo 2018（2018 年 5 月 30 日～ 6 月 1 日）｜AWS

セッションレポート

アジェンダ

なぜ移行したか
検証／設計
構築
リリース
運用
まとめ

ミイダスとは

2015年11月にオープンされた転職支援サービス
17万人以上の転職者ユーザと1万社以上の企業をマッチング

なぜ移行したか

そもそも

2014年社内の事業創出制度からプロジェクトスタート
スピード重視での実装
運用費用もローコストが求められていた
アプリケーションエンジニアがインフラも担当

何が起こるか？

サービス成長による変化

データ量が増える
バックアップデータも増える
- 毎月いくつかのサーバディスク容量拡張
- →面倒なオペレーション
- →クリティカルなサーバを扱う時にはサービスメンテが必要
バッチ実行時間も増える
CPU/メモリ利用率も上がる
- サーバのスケールアップ/アウトの発生
- →スケールアップと共に設定変更が必要
- →スケールアウトしたサーバのクラスタノードのせいで全体が不安定に

歴史的な理由でサーバ構築が煩雑に

元の構成の不満

サーバ上が整理されていない
- 同じ機能が別のサーバでも動いている
- →イメージバックアップの弊害
- ミドルウェアが乱立
- チューニングしづらい
バックアップサーバに処理が集中
ほぼ単一のサブネット上に配置

課題感

今後の成長に備えた構成にしたい

ユーザの拡大
メディアに取り上げられる際のスパイクを防ぐ
- スケールアップ/アウトを手軽に行いたい

手間のかかる作業をやめて開発に集中したい

マネージドサービスを活用したい
突発作業でもオペレーションミスが起きないものにしたい

構成と構築をシンプルにしたい

移行プロジェクト

課題を解決するために、移行を提案
2017年8月にスタート

チーム組成

移行担当チーム：インフラエンジニア3人

通常は他の役割と兼任
移行期間は主担当はほぼインフラ業務に専念
チームメンバーは、随時レビューしつつ、構築フェーズから合流

クラウドベンダーの選定

AWSとGCPで比較

費用の試算
- カタログスペック対費用はあまり差がない
- 利用したいマネージドサービスの多さでAWSに軍配
すでにAWSを一部利用していた
- CloudSearch、API Gateway、Lambdaの利用中
社内基幹システムのAWS移行
- ビジネスサポートを契約済み/他部署の利用

検証／設計

設計の方針

既存のアプリケーションにはなるべく手を入れない
- 開発スピードを落とさないことが目的
役割を整理してシンプルな構成にする
可能な限りマネージドサービスを利用
運用費用の削減が目的ではない
- インフラコストに見合うエンジニア工数の削減が目的

検証／設計

環境を作って、懸念点をつぶしていった
- 使い勝手
- 既存アプリケーションとの互換性
- セキュリティ
構成がまとまってから、資料を作成して担当のAWSソリューションアーキテクトの方にレビューいただいた
- フィードバックをもとにさらに設計を修正
全社でエンタープライズサポートを契約

AWS Loft Tokyoに期待

Amazon ECS

最初はEC2でやるつもりだった

構成がシンプルになる
依存関係が明確になる

随所でメリットが多いと判断、利用することに

取扱	EC2	ECS
ミドルウェアの管理	Ansible	Docker image
ソースデプロイ	rsync	Docker image
バックアップ単位	AMI	Docker image
オートスケール	インスタンスが増減	ECSタスクが増減、コンテナインスタンスが増減