開発環境から本番環境までのDocker活用方法 / Fintech Engineer 20210604

Transcript

1. 開発環境から本番環境までの
 Docker活用方法
 クレジットエンジン株式会社　麻生隆道 
 1
2. 自己紹介
 クレジットエンジン株式会社
 麻生 隆道（あそう たかみち）
 
 • バックエンド・フロントエンド・インフラを担 当
 • 副業からジョインし、現在はCTOをやって ます
 • 前職は12年ほど組み込みエンジニアやっ てました
 2
3. アジェンダ
 • 会社・プロダクトの紹介
 ◦ 技術スタックの紹介
 • 開発環境での Docker 利用事例
 ◦ 良かったこと
 ◦ つまづいたこと
 ◦ 悪かったこと
 • 本番環境での Docker 利用事例
 ◦ 良かったこと
 ◦ 悪かったこと
 • 他にやっていることを紹介

4. 会社・プロダクト
 紹介

5. Credit Engine の紹介
 中小事業者が融資を受ける際には
 様々な紙ベースの書類が必要であった
 
 
 オンラインで完結するので簡単に使え
 空いた時間で本来の事業に集中できる
 5 “かす”をかえる。“かりる”をかえる。
 ミッション

6. CE Platform の紹介
 ミッション実現のため LENDY で培ってきたノウハウを
 プラットフォームとして金融機関などに提供
 6 三菱UFJ銀行
 『Biz LENDING』
 みずほ銀行
 『みずほスマートビジネスローン』

7. CE Platform の技術スタック
 アプリケーション・インフラは以下の技術スタックで構成しています
 フロントエンド：Vue.js（JavaScript）
 バックエンド：Django REST framework（Python）
 開発環境：Docker Desktop for Mac（2017年10月から利用開始） 本番環境：Amazon ECS / AWS Fargate（2019年12月から利用開始）
8. 各種環境について
 資料の中で出てくる各種環境について説明しておきます
 • 開発環境
 ◦ ローカルマシンで構築した開発用の環境
 • ステージング環境
 ◦ 本番リリース前の動作検証用にAWSに構築している環境
 • 本番環境
 ◦ 実際のサービスが稼働している環境
 • デモ環境
 ◦ 営業用に触ってもらうための環境
 • レビュー用環境
 ◦ PM・デザイナーがレビューする際に動作確認できる環境

9. 開発環境での
 Docker 利用事例

10. 開発環境でDockerを採用した理由
 ローカルのツール類の管理に
 時間を使いたくないし
 新人の環境構築を手伝うのは
 もうこりごりだ😋

11. どんなことが起きていたのか？
 Docker導入前に起きていた事例
 • インストール作業が多すぎて時間がかかる
 • 他のツールと競合してインストールできない
 • インストール忘れてて動かない
 • バージョンが違って動かない
 • クリーンインストールしてやり直したけどやっぱり動かない・・・😓
 
 環境構築に時間がかかり本来やるべき開発が進まない

12. Docker導入で良かったこと
 良かったこと：面倒な環境構築作業から開放されました😁
 • GitHub からソースを持ってきて docker-compose up で
 すぐに開発環境が立ち上がるように！
 • Windows / Linux でも同じ環境で開発できるように！
 
 環境構築の時間が削減・面倒なフォロー作業もなくなりました

13. Docker導入でつまづいたこと
 つまづいたこと①：イメージ作成にすごく時間がかかる問題😖
 • docker build でイメージ作成までに数時間かかってしまう
 • Python パッケージを追加するたびに待ち時間が発生
 
 ECR にビルド済みイメージをプッシュして共有することで回避
 
 そして別の問題が発生することになります・・・😁

14. Docker導入でつまづいたこと
 つまづいたこと②：イメージのプッシュ漏れが多発
 • パッケージ追加・アップデートの際はビルドしてプッシュする運用にしていた が、だいたいみんな忘れる😁
 • メンバーが増えたときに IAM を発行するのもめんどくさい
 • やはり、根本のビルド遅い問題を解決する必要がある
 • 原因はベースイメージに Alpine Linux を選択していたため、numpy や pandas などのパッケージを毎回ビルドしてしまっていた
 
 ベースイメージに Debian を選択することで回避できました

15. Docker導入でつまづいたこと
 つまづいたこと③：フロントエンドの node_modules ディレクトリ問題
 • 開発環境なのでソースを変更したらホットリロードで即座に反映してほしい ので、volumes でローカルのディレクトリをマウント
 • npm install で作成される node_modules ディレクトリまでコンテナ内に共 有される • ローカルの node_modules はMac用のバイナリが入っていて動かない 
 node_modules は data volume としてマウントして回避 （詳しい説明は割愛しますが Google などで検索すると出てきます）

16. Docker導入で悪かったこと
 悪かったこと①：デバッグ手順が煩雑になった
 • ローカルで Django を起動している場合は VS Code でブレークポイントを 設定するだけでデバッグできていた
 • コンテナ内にいるとブレークポイントが効かない
 • サーバサイドのデバッグは同様の問題があると思います
 
 止めたい箇所に breakpoint() を入れて実行後に docker attach でデバッ ガを動かせます（けど、使いづらいです💦）

17. Docker導入で悪かったこと
 悪かったこと②：動作が重い
 • Docker Desktop for Mac 特有の問題だとは思いますが、重いです • 今のところ回避策はないので Windows / Linux を使うほうがパフォーマン スは良いです • Apple Silicon だと解消しているかもですが、Docker イメージの ARM 版がない時があるのでお気をつけください
18. 開発環境に導入してみた総論
 いろいろとつまづきポイントは
 あったけど
 環境構築の問題がなくなったのは
 控えめに言って最高です😆

19. 本番環境での
 Docker 利用事例

20. 本番環境でDockerを採用した理由
 開発環境では動いてたのに
 ステージングに行くと動かなくなるし
 ステージングで動いたと思ったら
 本番になると動かなくなる、もう嫌だ😓

21. どんなことが起きていたのか？
 Docker導入前に起きていた事例
 • 新機能を追加したときに必要になるライブラリ・フォントなどを入れ忘れて、 ステージングで動かない
 • S3 を操作する機能を作ったけど開発環境ではローカルのファイル操作に 置き換えていたので、ステージングに行ったら動かない
 • 本番環境で起きた問題が開発環境で再現できない
 • ライブラリのバージョンが開発環境と違ってステージングで動かない
 
 本番環境と同等の環境がローカルでも動くようにしたい

22. 本番環境向けのイメージ作成でやったこと
 本番環境向けにはいくつかやらなければいけないことがあります
 • コンテナ内に脆弱性がないかチェックする必要がある
 ◦ Trivy
 ▪ OSのライブラリや各言語のパッケージに脆弱性が残ってないかをチェックして くれる
 ◦ Dockle
 ▪ Dockerfileの書き方に脆弱性がないかチェックしてくれる
 • 本番でしか使えないサービスをローカルで動かす必要がある
 ◦ LocalStack
 ▪ AWSの各種サービスのモック
 ◦ maildev
 ▪ メールサーバのモック

23. AWSでコンテナを動かすためには
 AWS上でコンテナを動かすための選択肢
 • EC2上でDockerを動かす
 • ECS / EC2
 ◦ ECSでオーケストレーション
 ◦ 実際に動作する環境はEC2上
 • ECS / Fargate　←　この環境を採用しています
 ◦ 実際に動作する環境はAWSのマネージド環境
 • EKS / EC2
 ◦ Kubernetesでオーケストレーション
 • EKS / Fargate
 ◦ 検討した当初はなかったので未検討

24. Fargateを選択した理由
 一言でいうと Fargate の方が考えることが減り管理コストが下がります
 • EC2バックエンドだと、何台動かすかを決める
 • オートスケーリングの設計をする
 • OSやミドルウェアのバージョンアップもやらなければならない
 
 AWS の責任範囲で対応できます（AWS責任共有モデル）
 その代わりコストは若干高くなります（約1.17倍）

25. Docker導入で良かったこと
 良かったこと①：環境依存の不具合から開放されました👍
 • 本番環境にデプロイする前にローカルでテストできるので、環境依存で動 かないケースがなくなりました
 • ただ、まだ発生してないだけで、完全に排除できたのかは分かってないで す
 
 同じ動作環境を気軽に持ち運べるのがコンテナ技術の強み

26. Docker導入で良かったこと
 良かったこと②：サーバのメンテナンスから開放されました👍👍
 • Fargate を使ったことでサーバのメンテナンスが不要になりました
 • コンテナイメージで使っているOSはイメージのメンテナーにお任せしている ので、最新版をプルして使うだけ
 • メンテナンスを担送しなければいけない部分は Python のパッケージ部分 のみに集約できました
 
 簡単にコンテナを運用できるのが Fargate の強み

27. Docker導入で悪かったこと
 悪かったこと：コンテナ内でのデバッグ作業がやりづらい
 • Fargate を採用すると本番環境のコンテナ内にログインして作業ができな かった
 • ただ、今まで本番環境のコンテナに入らなければならないケースは発生し ていません（そもそもリリース後は入れてはいけない）
 
 今は ECS Exec という機能が実装されたことで解消しています ただ、ECS Exec の設定はとてもめんどくさいです。。。

28. 他にやっている
 ことを紹介

29. インフラ構成管理ツールについて
 Infrastructure as Code（IaC）のツールでは Terraform がよく使われています が、クレジットエンジンでは AWS CDK を採用しています
 良かったこと
 • インフラ専任メンバーは居ないので、書きなれたプログラミング言語で書け る
 • デフォルトで設定がベストプラクティスに基づいて構築してくれるので、他の IaCツールと比べるとコード量が少ない
 悪かったこと
 • 頻繁に変更が入るので、一度構築したら触りたくないという方には向かな い（私はそんなに気にならない）

30. デモ環境・レビュー用環境について
 他にもDockerを使って以下のような環境を作っています
 営業用のデモ環境作成
 デモ環境作成の要望は毎月のように来ていたのですが、従来は半日作業で手動でやっ ていたのを、現在は1時間くらいで構築できるようにしました
 PM・デザイナーが動作確認するためのレビュー用環境
 元々、PM・デザイナーがエンジニア出身だったのでDocker動かしてもらっていたのです が、さすがにDocker詳しくない人も入ってきたので環境構築できるようにしました

31. デモ環境・レビュー用環境について
 実現方法としては以下のような構成です
 • CDKで以下のリソース設定を行う
 ◦ ECSのサービス作成（まだ起動していません）
 ◦ ALBへのリスナールールの追加
 ◦ Route53へのサブドメインの追加
 • CodeBuild / CodePipeline で以下を実行
 ◦ Dockerイメージの作成
 ◦ DBの作成と初期データの投入
 ◦ サービスの起動（ここで起動します）

32. この先やってみたいこと
 • AWS App Runner が発表されたので試してみたい
 ◦ コンテナ化されたアプリケーションが今までよりも簡単・迅速にデプロイ できるらしいです
 ◦ 今日のために試そうと思ってましたが時間取れず・・・
 
 • AWS以外のクラウド利用
 ◦ 金融機関では Azure も利用されるケースが多いので、Azure で気軽に コンテナ運用できるように環境づくりをしてみたいです

33. 33 最後に！
 一緒に働く仲間を募集しています
 他にも気になることがありましたら
 気軽にお問い合わせください
 https://creditengine.jp/