夏の AWS Fargate & Amazon ECS/EKS 祭り に参加しました

初めてAWS新オフィスにお邪魔しました！
特にユーザ事例のお話はとてもためになって、すごく満足度が高い会でした。

特に、「理想状態への収束」というキーワードは、最近特に気にしていることで、
今の仕事にも積極的に活かそうと思いました。

f:id:iryond:20180803170155j:plain:w300

Kintone on EKS Cybozu 野島さん

  • Kintone：業務アプリケーションを業務ユーザが作るためのプラットフォーム
  • US向けにサービス展開→AWSで展開
  • メンバーは10人程度,2~3名のチームに分割
  • 1アカウント、チーム分VPCを作っている
    毎日夜8時に完全削除、毎朝5時に新規作成、すべてIaC
  • Ingress→Nginx→APのような構成、DBはAuroraでEKSの外側
  • なぜEKSに乗せたか？
    →「手順」ではなく「理想状態」を与えてデプロイできる

「理想状態への収束」

  • いわゆる"手順"は差分的な考え方
    →「現在の状態」と「理想の状態」の差分
  • 差分を自動化で積み重ねていくと、結局ヒトがツールのために働かないといけなくなる
  • ロバストな自動化のためには「理想状態への収束」を実現する必要がある
  • DB/NW : CloudFormation , LB/AP : EKS

継続的インテグレーション

  • 使われていない自動化は壊れていく
    →常に自動構築を動かすことが非常に大事
  • Git PushするたびにCIで変更を開発環境に適用する
  • 一日一回CIでVPCを削除してゼロから再構築する
    →ゼロから環境が作れることを保証
  • Kubenetesの マニフェスト を用意して、 kubectl apply で適用する
    →CloudFormation書いてdeployするイメージ
  • 初期データの作成などは、以前はSQLでべた書きしていたが、
    今はサービスを管理するサービスを作って、RESTで初期化している

小ネタ

  • EKSだとPodにk8sの外からアクセスできる
    External-DNSを使ってPodのIPをRoute53に登録している

AWS FargateでElixirのコンテンツ配信システムを運用してみた エムスリー 野島さん

Fargate化してみて

  • アプリケーションデプロイまでの時間が高速化された
    20 -> 10min
  • プラットフォームの構成変更が楽になった
  • ローカル環境でプラットフォーム自体のテストができるようになった
    • Deploy hookなどが実機じゃないとテストできなかった
  • デプロイパイプラインを管理しやすくなった
    CodepipelineからECSへのデプロイが非常に楽、AWSで完結できるので非常にシンプル

従来のElasticBeanstakの構成と課題

  • Beanstalkがネイティブでサポートしていないため、Erlangのビルドが必要だった
    →ビルドに1時間ほどかかっていた、結果としてビルドしないために.ebextensionを使うように。
    「インフラ管理の離別が発生してしまった」
  • TerraformがElasticBeanstalkのカスタムプラットフォーム構築のための必須パラメータとなるPlatformARNがサポートされていなかった
    →Terraformに手を入れていたが、Terraformのバージョンアップへの追随がつらくなってきた

エムスリーのシステムとElasticBeanstalkが合わなかった

Fargate化後の課題

  • コンテナはシングルプロセスなので監視用のプロセスなどをどう実装するか
  • buidspec.ymlがAPリポジトリ内にしか置けないので、CodeBuildがAPリポジトリに依存する
  • AWS利用料が割高

EKS / Fargate コンテナの運用監視は今までと何が違うのか？よくある課題とその対策 Datadog 服部さん

EKS / Fargate ってどう監視したらいいんですか？

  • データ収集・保存→可視化→アラート→問題分析→インシデント管理
    • データを取る、そして使う
    • コンテナ環境ではデータを取るプロセスに特徴あり
    • モニタリングが特別すぎるわけではない

大前提：コンテナ化によるビジネスアジリティの享受

  • 依存関係の地獄からの脱却
  • 圧倒的なスケーラビリティの獲得
  • 超軽量で高速なデプロイ

「導入したものの運用上これらを失うような状況に陥らないように。」

  • 注意すべきポイント
    • コンテナそのもののメトリックもとる
    • スケーラビリティが出すぎて監視がスローダウンしないように
    • デプロイしたばかりのコンテナイメージのアップデートを塩漬けにしない(≒既知のバグを踏まない)

コンテナを運用するとどうなるか？

www.datadoghq.com

「導入したとたんに急拡大する」
「ライフサイクルが異常に速くなり、集積度などが大きく変わってくる」

  • モニタすべきメトリック・イベント・ログは激増する
  • 今まで以上に物理的/論理的なレイヤーが増える

膨大で多層にスケールするシステムのモニタリングとは？

  • 従来のサーバー監視：サーバーホスト中心
    サーバーの登録・サーバの役割設定
  • スケーラブルなモニタリング：サービス中心
    タグやラベルによるクエリベースのモニタリング
    #role:web,#nginx,5xx,#instance:c4-xlarge,#xxxxxxなど

"The Three Pillers of Ovservability"