この記事は公開されてから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タスクが増減、コンテナインスタンスが増減 |
ECSへの変更
良かったこと
- そもそも開発端末で動く環境としてDockerを利用していたため、設定が流用できた
- ローカルの開発環境から本番環境まで、動作環境の統一
- インフラエンジニア以外もミドルウェアメンテナンスに協力しやすい
- くせのあるミドルウェアでも、コンテナで導入しやすい
- Debian/Ubuntuしか公式サポートされていないHHVM
- ヘルスチェックによってコンテナが再起動して復旧する
- プロセス監視が不要
ECSを実際に運用してみて
クラスタ作って、動くようにするまでにはコストがかかる
- CloudFormationに対する慣れ
- ECSクラスタへの起動設定やAutoScalingグループへの設定がCloudFormationで上書きされる
- 設定箇所が多くてつらい
- ECS-CLIでdocker-compose.ymlを用いてタスクの作成を行える
- →ECSへのロックインを防ぐメリットも
- デプロイ手順が増え、遅く感じる
構成を変更しなかった点
Batchサーバ
- 一部バッチにサーバにステートを持って連携をする処理があったため
- 代替案を検討中
- →AWS Batch、ECSスケジュールタスク、SQS＋Lambda
NFSサーバ
- S3＋Goofysを検討した
- AWS SAの方が「おすすめしない」
- ファイル操作時にS3のHEADやLIST APIを結構叩く
- --cheapオプションもあるが速度とのトレードオフ
- Amazon EFSの東京リージョン待ち
- 昨日の発表があって歓喜
設計で参考にした資料
AWSクラウドサービス活用資料集
- 呼応式に日本語ドキュメントがあって心強い
- 行き詰ったときなどに読んでいた
Developers.IO
- 新しいサービスの資料が早くてありがたい
構築
- 2017年10月～12月
- 設計通りに構築して、構築手順を作成した後、テストケースを作成し、その環境の上で正しくアプリケーションが動くか確認した
開発/ステージング環境の構築
- 構築手順と実際に動く環境を参考に、チームメンバーそれぞれが環境を作成し、お互いにレビュー
- チームメンバーのキャッチアップが目的
- 必然的に全てのサービスを触ることになり、実践的に仕組みを学べた
リリース
移行作業
- 2018年1月下旬
- リハーサルを2回して、手順と時間を把握
- 夜22時～翌17時までサービス停止
運用
ログ・監視
- ログ：CloudWatch LogsとLogサーバ両方に収集
- メトリクス：CloudWatchに集約
- アラート：alarmを設定し、Amazon SNSとLambdaで通知
BI
- MetabaseでKPI可視化
- Tableauで分析
- 定期的にメインDBのReaderノードからダンプファイルを出力してBI用DBに投入
- AWS DMSで運用していたが、しばらく粘ったが挫折
- →UTF8MB4に非対応、インデックスを作成するタイミングが難しい
まとめ
実際のスケジュール
- 2017年8月：検証開始
- 2017年9月：設計、サンプル構築
- 2017年10月：構築
- 2017年12月：開発環境の作成、チーム内キャッチアップ
- 2018年1月：テスト
- 2018年1月下旬：リリース
移行の作業工数
ざっくり12人月程度
- 検証・設計：1人で4ヶ月
- 構築：3人で2ヶ月
- テスト：2人で1ヶ月
費用
移行前より費用は増えた
- 役割を分割して、フルマネージドにのせた
- 可用性を考慮し、マルチAZ構成にした部分
費用対効果を考えると妥当な金額に
改善されたところ
- メンテナンスが楽に
- メンテ対象が減った
- 16台の仮想サーバ→10台のEC2インスタンス
- 減った分はフルマネージドに移行
- インフラ由来のアラートは明らかに減った
- ECSは管理コストが低い
- コンテナ内にトラブルがあったら、自動的に立ち上がり直す
- ミドルウェアはDockerの管理だけ
課題は解決できた？
- 今後の成長に備えた構成
- →ECSやマネージドサービスで可能
- 手間のかかる作業をやめて開発に集中したい
- →マネージドサービスの利用
- →オペミスが起きにくい
- 構成と構築をシンプルにしたい
- →機能ごとにまとまり、シンプルになった
感想
AWSへ移行し、マネージドサービスを利用することで成果が出た良い事例だったなと思いました。
本番環境をECSで稼働させているシステムどのくらいあるかは分かりませんが、実際に触って検証したり、AWS SAの方にレビューをしてもらったりしながら進めれば、確実な移行ができることが分かりました。
マネージドサービス活用へのアプローチの良い参考になりました！
24
