$30 off During Our Annual Pro Sale. View Details »

jawsug_niigata_20220115

kaminchu
January 15, 2022

 jawsug_niigata_20220115

kaminchu

January 15, 2022
Tweet

More Decks by kaminchu

Other Decks in Technology

Transcript

  1. 会社のサービスをAWSへ移行した話
    JAWS-UG 新潟#11
    1

    View Slide

  2. 自己紹介
    twitter: @kam1nchu
    所属
    ウォーターセル株式会社
    経歴
    2017年入社
    フロントエンジニアで入社していつの間にかインフラエンジニア
    AWS歴=JAWS-UG 新潟支部 発足から
    2

    View Slide

  3. アジェンダ
    アグリノートとは
    AWSへ移行する目的
    移行前後の構成
    移行の流れ
    移行してよかった
    今後
    その他もろもろ(時間調整)
    3

    View Slide

  4. アグリノートとは
    ブラウザやスマホから利用する営農支援ツール

    https://www.agri-note.jp/
    4

    View Slide

  5. AWSへ移行する目的
    スケールアップ/アウトを容易にしたい
    ミドルウェア更新サイクルを早くしたい
    現行環境の老朽化
    コストの最適化
    5

    View Slide

  6. AWSへ移行する目的
    スケールアップ/アウトを容易にしたい
    すでに性能がギリギリになってきていた
    これからも拡大していく方針
    現状では性能"だけ"あげるのでも結構手間がかかる(特に精神的に)
    6

    View Slide

  7. AWSへ移行する目的
    ミドルウェア更新サイクルを早くしたい
    セキュリティの問題
    開発のモチベーション
    7

    View Slide

  8. AWSへ移行する目的
    現行環境の老朽化
    CentOSのEoL問題
    Systemd化の流れ
    8

    View Slide

  9. AWSへ移行する目的
    コストの最適化
    当初は目的としていたが、それほど安くならない(むしろ高くなる)
    ことが判明
    目的からは外した
    9

    View Slide

  10. 移行前後の構成
    移行前
    10

    View Slide

  11. 移行前後の構成
    移行後
    11

    View Slide

  12. 移行の流れ
    リフト&シフト
    コンテナ化
    デプロイの構築
    本番の移行
    12

    View Slide

  13. 移行の流れ
    リフト & シフト

    無理
    13

    View Slide

  14. 移行の流れ
    リフト & シフト
    当初は計画したが、EoLの見えているOSのまま移行するわけにも行
    かず、initd→systemd移行もそれなりの労力に
    デプロイもかなりの書き換えが発生してきて辛い
    もう、いきなりクラウド環境に最適化した形にしても構築の労力そん
    なにかわらないのでは。。。?
    ということで、fargateを選択
    14

    View Slide

  15. 移行の流れ
    コンテナ化
    サービスの分離

    これまでは、unicorn、delayed_job、cron(1台のみ)が同じインスタ
    ンス上で実行されていた

    それぞれ分離し、専用のコンテナ(task)で実行するようにした

    ただ、イメージは同じものとなるように
    15

    View Slide

  16. 移行の流れ
    デプロイの構築
    今までは担当者のPCからansibleやfabricを叩いてた
    移行後は社内のciからよしなにデプロイできるように
    社内ciに寄せるため、あえてcodepipelineは使わずにcode-deploy
    のみ利用
    16

    View Slide

  17. 移行の流れ
    本番への移行
    一日停止させてもらって、pg_dumpやs3 syncでゆっくり
    環境の切り替え自体はRoute53で
    17

    View Slide

  18. 移行してよかった
    サービスの棚卸しになった
    デプロイの簡略化
    ミドルウェアの更新も容易に
    メトリクスやログが見やすい
    18

    View Slide

  19. 移行してよかった
    サービスの棚卸しになった
    アグリノートでどんなサービスが存在するかすべてに目を通すいい
    機会になった
    誰も存在に気づいていなかったやつなどもあった
    19

    View Slide

  20. 移行してよかった
    デプロイの簡略化
    (ほぼ)すべてデプロイをciでの実行に変更
    これまではデプロイ環境を持った人間しかデプロイできなかった
    が、(ある程度は)誰でもデプロイが可能に
    実質、ほぼ私がデプロイ作業している状態だったので楽になった
    20

    View Slide

  21. 移行してよかった
    ミドルウェアの更新も容易に
    Dockerfileを書き換えるだけで良くなった
    コンテナの差し替えでできるのですごい楽に
    21

    View Slide

  22. 移行してよかった
    メトリクスやログが見やすい
    とりあえず標準出力に吐きまくるだけ
    CloudWatch Logs Insightsがかなり強力
    メトリクスは何もしなくても大体は集まってる
    alartの設定とかはちまちま作り込む必要はある
    22

    View Slide

  23. 今後
    コスト最適化
    オートスケーリング
    23

    View Slide

  24. 今後
    コスト最適化
    開発サーバー等で未利用時間は停止するように
    spotインスタンス等をうまく活用
    負荷を見極めて最小限の性能に
    24

    View Slide

  25. 今後
    オートスケール
    現在は aws ecs update-service を手動で叩いて調整してる
    負荷の相場が見えてきたらオートスケールにしたい
    25

    View Slide

  26. 26

    View Slide

  27. その他
    nginxをcloudfrotへ
    fargateのインスタンスどうしてもサービス化したいとき
    DBが離れたためちょっと遅くなった
    CloudFrontのタイムアウトが意外に短い
    27

    View Slide

  28. nginxをcloudfrotへ
    移行前はnginxでかなり複雑なルーティング等をやっていた
    移行後はnginxをやめて、cloudfrontにしたかった
    複雑な部分はLambda@Edgeを使って気合で実装した
    Lambda@Edge使うと意外となんでもできることがわかった

    →jsに慣れてたのも大きい
    28

    View Slide

  29. fargateのインスタンスどうしてもサー
    ビス化したいとき
    一部どうしてもサービス化して実行する必要のあるものがあった
    supervisordを使うことでいい感じにできた
    ※ ただし、サービスがダウンしたときの再起動はfargateではなく
    supervisord任せになってしまった
    29

    View Slide

  30. DBが離れたためちょっと遅くなった
    一部サーバで、apiとDBが同じサーバーで動いていたのを、RDSと
    apiサーバーの構成に変えた
    大量のクエリでやり取りする処理で時間がかかるようになってし
    まった
    サーバーの実装をよしなに変えてもらった
    30

    View Slide

  31. CloudFrontのタイムアウトが意外に短

    CloudFrontのリクエストタイムは30秒まで
    オンプレ系からの移行では意外と盲点かも
    クォータの引き上げの申請が必要
    31

    View Slide