Download as PDF, PPTX
![ログファイル2種• 全行のファイルとエラーだけの行を分けたい• エラーだけの行を Zabbix agent で監視• コンテナの標準出力は以下のように設定(見やすいように改行していますが実際は1行です）ENTRYPOINT [ "/bin/bash", "-c", "$JAVA_HOME/bin/java $JAVA_OPTS -jar ./program.jar--spring.profiles.active=$SPRING_PROFILE| tee >(grep --line-buffered -e "^[0-9-]* [0-9:.]* ERROR.*" >>/path/to/error.log)| tee -a /path/to/main.log" ]](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fjjug20181215springbootwebapplicationawsecs-181217015537%2f75%2fSpring-Boot-Web-Docker-AWS-ECS-48-2048.jpg&f=jpg&w=240)
Uploaded byJustSystems Corporation
PDF, PPTX17,720 views
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
JJUG CCC 2018 Fall 登壇時の資料です。 #jjug_ccc #ccc_g1
Recommended
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2famazonauroratips-170307140000-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
![[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fawsxon18howfarstepfunctionsgo-211124111849-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More Related Content
What's hot
Similar to Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
More from JustSystems Corporation
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
- 1.Spring Boot のWebアプリケーションをDocker に載せて AWSECS で動かしている話#jjug_ccc #ccc_g1JJUG CCC 2018 Fall2018/12/15
- 2.自己紹介• 株式会社ジャストシステム 福嶋 航•Twitter @fukushiw• Java歴約20年、JavaでWebサービス作っています• #Java100 本ノックの人https://github.com/JustSystems/java-100practices
- 3.このセッションについて• 人生で初めて、WebサービスをDockerコンテナ化してAWS ECSを使ってプロダクションリリースしたものについての話です•AWS ECS や Dockerコンテナ について、基本的なところは把握されている前提になっています• まだまだ慣れていないことやわかっていないことがあるため、セッション後や懇親会でぜひ情報交換させてください
- 4.セッションの流れ1. システム構成（Dockerコンテナにしたもの、しなかったもの）2. 各自の開発環境とビルド・デプロイの流れ（マージリクエストの前にやることと後にやること）3.β環境と本番環境、環境ごとの設定の切り替え（Gitのブランチ・プロファイル・環境変数をうまく使う）4. 本番運用に向けた「その他」の必要なこと（ログ出力設定、監視設定）5. まとめ
- 5.
- 6.サービスの性質• 企業向けWebサービス• 24/7稼働•個人向けWebサービスに比べ、アクセス頻度は高くない• 取り扱うデータ量は多い（数百GB～数TB）
- 7.JJUG CCC 2018Springの資料UIコア機能 外部連携RDBキャッシュキャッシュキャッシュ主要機能３ RDB主要機能２ RDB主要機能１ RDBサブ機能３サブ機能２サブ機能１サブ機能６サブ機能５サブ機能４RDBキャッシュキャッシュキャッシュRDBキャッシュサブ機能７ RDB各機能(コンテキスト)はそれぞれDockerコンテナとして動作（複数配置しALBで分散）し、REST APIでやりとり：
- 8.もうちょっと具体的に(抜粋)InternetWeb Server /UIcontainerothercontainersIndependentInstance2IndependentInstance 1GitLab
- 9.AWS ECSの採択経緯• 弊社はAWSをよく使っていた•Kubernetes の学習コスト懸念• AWS Fargate のランニングコスト懸念
- 10.Dockerコンテナにしたもの• ほぼすべての機能（十数種類のコンテナ）• AvailabilityZone A とAvailability Zone C にそれぞれ1つずつ配置（一部は2つずつ配置）• WebサーバのコンテナとUIのコンテナは同じタスク定義にして、他は別々のタスク定義にした（理由は後述）
- 11.Dockerコンテナにしなかったもの• 将来 AWSFargate にスムーズに移行できる自信がなかったもの• 他ファイルシステムのボリュームをマウントしたり、バッチやWebサービスが協働して動作する機能• crontabに慣れ親しんでいているため、精神的に「EC2インスタンスだからいざとなればなんとかなる」と安心したかった機能当然、Dockerコンテナにしてもできる。できるのだが、なんか、保険的な・・・。
- 12.WebサーバとUIのコンテナInternetWeb Server /UIcontainerothercontainersIndependentInstance2IndependentInstance 1GitLab
- 13.WebサーバとUIのコンテナ(拡大図)こうなっていますWeb Server UIcontainerInternet宛先 https:443 http:80 http:8080Web Server UI container
- 14.WebサーバとUIのコンテナWeb Server UIcontainerInternet宛先 https:443 http:80 http:8080 http:8080本当はこうしたかったWeb Server UI container
- 15.WebサーバとUIのコンテナX-Forwaded-ForX-Forwaded-ProtoX-Forwaded-Port---オリジナルIPhttps443オリジナルIPhttps443Web ServerのIPhttp8080Web ServerUI containerInternet宛先 https:443 http:80 http:8080 http:8080Web Server UI container
- 16.WebサーバとUIのコンテナX-Forwaded-ForX-Forwaded-ProtoX-Forwaded-Port---オリジナルIPhttps443オリジナルIPhttps443Web ServerのIPhttp8080Web ServerUI containerInternet宛先 https:443 http:80 http:8080 http:8080Web Server UI container
- 17.WebサーバとUIのコンテナX-Forwaded-ForX-Forwaded-ProtoX-Forwaded-Port---オリジナルIPhttps443オリジナルIPhttps443Web ServerのIPhttp8080UI containerにいる Spring Boot のリダイレクト応答(http:8080宛て）を 右側のALB が戻してくれず詰んだ（解決方法がわからなかった）Web Server UI containerInternet宛先 https:443 http:80 http:8080 http:8080Web Server UI container
- 18.WebサーバとUIのコンテナで結局こうしたInternet宛先 https:443 http:80http:8080Web Server UI containerWeb Server と UI container の Dockerコンテナを分けずに同一にするのは、「1コンテナ1アプリケーション」のベストプラクティスに反するので、踏みとどまったWeb Server UI container
- 19.再掲InternetWeb Server /UIcontainerothercontainersIndependentInstance2IndependentInstance 1GitLab
- 20.
- 21.各自の開発環境• PC• メモリは16GB以上必須(24～32GBは欲しい)•Windowsが多数派、Macな人もちらほら• IDEはほぼ皆何かしら使っている• Eclipse• IntelliJ IDEA• Visual Studio Code• など• Git• 一番早いのはコマンド :nerd_face:
- 22.マージリクエストまで• Issueを作る/アサインする• 粒度はまちまち•コーディング、テスト• ローカル用プロファイルで動作させる Spring Bootアプリケーションが入った Dockerコンテナをビルド・起動• 単体テストは、他マイクロサービスのところはモック• コードの自己レビュー
- 23.マージリクエスト• 担当者以外が保守できるか、を最重視• 実装理由のコメントや、APIドキュメントも重視•複雑なロジックはじっくり読む• マージ前の動作確認まではできなかった• 相当な量がやってくるので、時間的に無理• マージ後の確認でSpring Boot起動時にエラーになるとか、コンパイルエラーになるものもまれに……このあたりはシステム化したかったが、できなかった
- 24.マージ後• GitLab CIで開発環境にデプロイ•特定のブランチへのPUSHで以下を自動実行 jarビルド (mvn clean install) ↓ Dockerイメージビルド (docker-compose build) ↓ ECRに登録 (docker push) ↓ ECSのタスク定義＆サービス更新 (ecs-deploy) ↓ Mattermostに通知 (curl)• GitLabでそのブランチにPUSHできる人を限定• 複数の環境ごとにブランチを用意(後述)
- 25.
- 26.すぐにデプロイされない罠• Dockerコンテナをホストポート固定で動作させる場合、1つのEC2インスタンスでは同一タスクは1つしか起動できない。ここで EC2インスタンス数＝タスク数にすると、デプロイ時の動作は タスク停止→draining→タスク起動となる。新しいタスクの起動が前のタスクのdrainingが完了するまで待たされるのですぐに新Dockerコンテナが起動しない。• ホストポートをダイナミックにすれば関係ない
- 27.
- 28.Case1 インスタンス数＞タスク数Container A1タスク定義=A1:1Instance 2(1)Instance1でA1:1タスク実行中Instance 1
- 29.Case1 インスタンス数＞タスク数Container A1タスク定義=A1:1(2)新しいタスクA1:2はすぐにInstance2にデプロイ され、A1:1 は draining に。Instance 1Container A1タスク定義= A1:2Instance 2draining
- 30.Case1 インスタンス数＞タスク数(3)drainingされたコンテナは消えるInstance 1ContainerA1タスク定義= A1:2Instance 2
- 31.
- 32.Case2 インスタンス数＝タスク数Container A1タスク定義=A1:1(1)Instance1とInstance2でA1:1タスク実行中Instance 1Container A1タスク定義= A1:1Instance 2
- 33.Case2 インスタンス数＝タスク数Container A1タスク定義=A1:1(2)片方のインスタンスでdraining、もう一方は A1:1のままInstance 1Container A1タスク定義= A1:1Instance 2draining
- 34.Case2 インスタンス数＝タスク数Container A1タスク定義=A1:2(3)drainingが完了すると新しいタスクがデプロイ され、もう一方がdrainingになる。Instance 1Container A1タスク定義= A1:1Instance 2draining
- 35.Case2 インスタンス数＝タスク数Container A1タスク定義=A1:2(4)drainingが完了すると新しいタスクがデプロイ される。Instance 1Container A1タスク定義= A1:2Instance 2
- 36.drainingにかかる時間• ターゲットグループの属性「登録解除の遅延」で指定• 新しいタスクをデプロイすると、すぐには置き換わらず、ここで指定した時間が経過するまで待たされる•タイムアウトを長くすれば、処理中が途中で中断されるリスクは下がるが、デプロイに時間がかかってしまう
- 37.
- 38.
- 39.β環境1• 各マイクロサービスが最初に結合を行う環境• 更新サイクルが早い•本線には取り込まない可能性があるものもここで試すことは可能（敷居が低い）• とはいえ影響のあるものは Mattermost で声を掛けてから
- 40.β環境2• 第三者評価を行う環境• 開発チームがβ環境1で確認を終えているものがデプロイされる•デプロイ手順も含めて本番環境に投入する前のリハーサルの場となる
- 41.β環境3• 性能評価を行う環境• インスタンスタイプや台数は本番環境と同じ•負荷を掛けて、本番環境に必要なインスタンスタイプやECSタスクの個数、割り当てメモリ等を導き出すための材料を得る
- 42.
- 43.ブランチの切り替え• ブランチポリシーは GitFlow を採用• master, develop, feature, release, hotfix• GitLab CI でビルドする際は、環境ごとに別々のブランチにPUSH• β環境1ビルド・デプロイ用ブランチ、同2用、同3用• 本番環境ビルド・デプロイ用ブランチブランチを分けることでミス防止
- 44.環境変数の利用• Spring Framewokはプロパティファイルよりも環境変数を優先してくれるので、Docker イメージを作り直すことなく、ECSタスクの環境変数の変更（とサービスの更新）だけで動作設定を変更できる• Dockerイメージビルドして、ECRにアップロードして、・・・は、数分～十数分かかることも• ECSタスクの変更だけであれば数十秒のWeb画面操作だけで更新完了
- 45.
- 46.ログ出力（要件）• 同一種類のコンテナのログは時系列に見たい• あとで分析に使えるようにしたい•エラーレベルのものは監視アラートを出したい
- 47.ログ出力（構成）Log ServerS3 BucketcontainersonEC2filefluentdmountEC2instancemainerrorZabbixagent
- 48.ログファイル2種• 全行のファイルとエラーだけの行を分けたい• エラーだけの行をZabbix agent で監視• コンテナの標準出力は以下のように設定(見やすいように改行していますが実際は1行です）ENTRYPOINT [ "/bin/bash", "-c", "$JAVA_HOME/bin/java $JAVA_OPTS -jar ./program.jar--spring.profiles.active=$SPRING_PROFILE| tee >(grep --line-buffered -e "^[0-9-]* [0-9:.]* ERROR.*" >>/path/to/error.log)| tee -a /path/to/main.log" ]
- 49.監視内容（プログラムの外側）• エラーログ監視• Zabbixagent がエラーログファイルの変更を監視• EC2インスタンス監視（CPU/メモリなど）• ECS監視（リザーブ領域との対比等）• Docker space は特に重要• Webアクセス監視などなど
- 50.監視内容（プログラムの内側）• ヘルスチェック• ALBからのヘルスチェックのエンドポイントを作成•各マイクロサービスが依存するRDBやキャッシュへの通信の疎通まで確認。204 or 500 で応答。• アプリケーションメトリクス• 処理キューの長さ、動作スレッド数、など• 重要処理の処理時間も入れたかったが、これから
- 51.
- 52.コンテナ間通信が502エラーInternetWeb Server /UIcontainerothercontainersIndependentInstance2IndependentInstance 1GitLabここの通信が502になる1日に数回から十数回発生原因不明リトライで対処中誰か教えてください:pray:
- 53.
- 54.まとめ• Spring BootアプリケーションのマイクロサービスはAWSECSで普通に使える• Webサーバと入口のコンテナだけ1つのタスクに同居させ、他は別々のタスクにした• Dockerコンテナ入れ替え時の待ち時間に注意• 3つのβ環境を含めた4環境で別々にGitLabCIでビルド・デプロイ、環境変数を活用• ログはコンテナから母艦経由S3へ• 監視はプログラムの外側と内側の両方