SREディレクター の @ntakaaki です。フォトクリエイトではAWS・社内両方のインフラを担当してるチームのリーダーをしています。
この記事は Photocreate Advent Calendar 2018 の 6日目 の記事です。
はじめに
フォトクリエイトでは今年5月に創業以来使っていたデータセンターにあったシステムをAWSに移行しました。
AWS自体は新規事業やオウンドメディアなど既存システムとのしがらみがない部分で数年前から機会を見つけて利用を進めてきていたので、全くのゼロから始めたというわけではありませんでしたがこれまでの使い方はクラウドネイティブと言うには程遠い使い方でした。
最近ではオンプレからデータセンターに移行してシステムが新しく刷新されたという事例もよく見かけるようになってきました。
弊社もAWSに移行したとはいえ、いわゆるリフト方式でかなり突貫でやってしまった部分もありDC時代の負債を引きずってる部分があるのが現状です。
というわけで、AWSに移行してこうなったというよりはAWSに移行する前にこれをやっておけばよかったというのを自戒の念を込めつつ振り返り、これから移行を進めていかれる方の参考になるような情報を提供できれば幸いです。
ざっくり移行までの流れ
- 2017年11月某日 AWSへの移行を最優先で進めるとの決定が下る
- 2018年1月28日 DBと主要なサービスのWebサーバーを移行
- 2018年4月2日 決済処理のシステム、B2B関連のシステムを移行
- 2018年4月末 バッチ処理関連のシステムを移行
- 2018年5月14日 社内用管理系システムを移行
なぜDBからやってるのかというと、とにかく当時DBのスケールアップを優先したかったというのがありました。当社の繁忙期が、弊社社内では一大イベントとなっている東京マラソンをはじめとしたマラソン大会や幼稚園・学校の卒園式などのイベントが重なる2月から3月になるため、それまでにDBと主要なサービスのスケールアップを済ませておきたかったという理由になります。
移行前の構成
前述したとおり今年5月にオールスポーツ、スナップスナップなどのサービス群と社内用の管理システム、プリントオーダー用のサーバーなどをAWSに移行しました。
DC時代の構成はオーソドックスな構成でFW > Web > DB（マスタ、スレーブ）と他に管理画面やバッチなどの用途に特化したサーバーとストレージででなんとか1ラックに収まるくらいの規模の構成でした。
AWS移行後の状況
AWSに移行してもこの構成は大きくは変わってませんが現在は、主要なサービスの構成は以下のようになってます。
CloudFront > ALB > EC2 > DBとKVSがEC2、セッション管理にElastiCache
他、バッチ用などのEC2がいくつか動いてる状態です。
これ先にやっとけばよかった3選
AWS移行や移行後の運用をスムーズにするためにやっておけばよかったというのは上げればキリはないのですが、その中でも特に3つほど。
AWSアカウントの分割の検討
DCのシステムを移行する際に、すでに運用してるシステムと同じAWSアカウント（IAMではありません）で構築を進めてしまったのは失敗でした。
一つのAWSアカウントですべてのサービスを管理しているので、
- リソースの変更や削除が意図せず他のサービスに影響してしまうリスクを抱えている
- サービス別のコストの正確な把握ができない（タグを振ることである程度は可能）
といった課題があります。
現在これらの課題を解消するべくAWS Organizationsを利用を検討しています。
もちろんOrganizationsを導入してもいいことばかりではなく、IAMのアカウント管理をどうするかやCloudtrail等の各種ログの管理対象が広がってしまうなど、複雑性も上がってしまうので、事前の設計には時間をかけるべきでしょう。
Sandbox的なアカウントや環境を用意することで、エンジニア毎にAWSのいろんな機能をより触りやすい環境として提供するなどをすすめたいと思います。
などといっているうちに先日のre:Invent2018でControl Tower がリリースされました。早速Previewに申し込んだので、利用できるようになったら検証したいと思います。
参考URL
https://aws.amazon.com/jp/controltower/features/
ディプロイの自動化
DC時代のディプロイの方式はアプリによっていくつか方式がありましたが一番利用頻度が高く依存度が高かったのはrsyncをベースにしたものでした。
時間的制約もありこの部分の手を入れずにそのままDCに移行しましたが、後のインスタンスの増減などの構成の変更のたびに手を入れなければならないなど、メンテが大変な箇所になってしまいました。
AWS移行がどうのこうのというより前に、このいけてない仕組みを取っ払っておくべきでした。
サーバー間のファイル共有
困ったのがFTPやSCP、rsyncなどでサーバー間で直接ファイルを送受信してる箇所です。
DC時代にNFSなどの共有ファイルシステムがなかったのでこんな仕組みになってしまってました。
特にFTPはAWSで使うには癖があります。
AWSでもFTPが使えないわけではありませんが、ポートの開放の範囲や通信の向き、ActiveかPassiveで通信するのかなど考慮することがあり何かと面倒くさいです。
自分はFTPで通信してる箇所はそのまま移行するのを止めてscpやrsyncに置き換えてしまいました。
またいつインスタンスの増減があるかわからない環境で、IPやホストを直接指定する形で
プッシュでファイルをやり取りする方法は悪手と言えるでしょう。
（タグからIPを取得するという方法もあるでしょうが）
ユースケースにも夜でしょうが、ホスト間の直接の通信でファイルをやり取りするよりはS3やEFSなどのストレージの利用を検討するべきでした。
最近はSSMのRunCommandで受信側のインスタンスがS3からファイルをプルするやり方に置き換えつつあります。
先にやっててよかったこと
駄目なことばかり書いててもあれなので、先にできててよかったことをいくつか。。
SSH用認証基盤
インスタンスへのSSH認証ですが、DC時代はLDAPではなく各マシンに都度設定していました。
流石にAWSでそれはやってられないだろうということになり、STNSというLDAPに似た仕組みで認証するようにしました。認証情報のDBもDynamoDBで管理するようにしています。
参考URL
https://stns.jp/
https://qiita.com/shogomuranushi/items/f09fcdeb146b45452403
メール送信
AWSへの移行を機にメールの送信をこれまでサーバー内のMTAから送信していたのをSendgridに変更しました。
日本固有のRFC違反なアドレスのPostfixでの扱いやEzwebのSenderID設定などでハマることもありましたが、Sendgridのドキュメントどおり事前のウォームアップやDomain Authenticatorの設定などは済ませて徐々に移行することで、特に問題なく移行できました。
参考URL
https://sendgrid.kke.co.jp/docs/
https://www.au.com/mobile/service/attention/spf-record/
まとめ
一応AWSにシステムが載ったとはいえ、まだまだDC時代のつらみを抱えてる部分が残ってる状態です。
が、この部分をクラウドに最適化した形に作り変えていくのを現在進行中です。
先週のre:Inventでまた新サービスも発表され進化しているAWSに合わせて、今のシステムをどう進化していくか考えていくのは学びも多くやりがいのある仕事だと思っています。
フォトクリエイトではAWSなど、世の中で進化しているサービスを取り込みながら、ともにプロダクト・エンジニアとして進化していきたい方からの ご応募をお待ちしております。