ちょっと話題の記事

コンテナのアツい鼓動と変な熱気に包まれたJAWS-UG コンテナ支部に参加してきた #jawsug_ct

コンテナ界隈の熱気を感じるJAWS-UG、コンテナ支部のイベントに参加してきました。
2018.06.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

「コンテナ界隈、あっつあっつやで…」

クラスメソッドAWS事業部におりますと、そりゃいろんなJAWSのイベントにお伺いすることが良くあるんですが、自分コンテナ支部ははじめての参加でした。

JAWS-UG コンテナ支部 #12 - connpass

いやぁコンテナ界隈はアツい。参加者も大人数で楽しい時間を過ごさせてもらいましたので、その熱気をご報告致します(冒頭画像は、上記イベントページのトップ絵を借用させていただいております)。

 __
(祭) ∧ ∧
 Y  ( ゚Д゚)
 Φ[_ソ__y_l〉     コンテナ ワッショイ
    |_|_|
    し'´J

ごっつ素敵なエウレカ様オフィス

今回のJAWS-UG コンテナ支部の会場はeureka, Inc.のオフィスでの開催となりました。

自分にとっては初耳の会社様だったのですが、Pairs(ペアーズ) - Facebookを利用した恋愛・婚活マッチングサービスと聞けば、ピンと来る人も多いんじゃないでしょうか。自分のtwitterのタイムラインにも、ごっつでてきます(真顔)。

会場の様子。今どきの広々として明るいスペース。素晴らしいすね。スクリーンも2台設置。

壁面も綺麗でお洒落。

この反対側にはガラス張りで区切られたエウレカ様のオフィスがババーンとでてました。ババーンとね。

JAWS-UG コンテナ支部 #12の講演内容

JAWS-UG コンテナ支部 #12 - connpass

タイトル 講演者
Amazon Elastic Service for Kubernetes (EKS)の紹介 Amazon Web Services Japan 福井 厚さん
FiNCを支えるインフラ技術 〜ECSとDevOps〜 株式会社 FiNC 中村 郷史さん
AWS初学者がDevOpsツールを作ってみた 株式会社ビズリーチ様
EKSにシュッと入門〜GKEからの移行〜 株式会社エウレカ SRE チーム 坂田 純さん

その他にもLTがあったのですが、今回は割愛させていただいてます。

Amazon Elastic Service for Kubernetes (EKS)の紹介

トップバッターはアマゾンウェブサービスジャパン株式会社の福井 厚さん。

この間のAWS Summit Tokyo開催直後に発表されたEKS(Amazon Elastic Container Service for Kubernetes)について、話を伺います。

EKSとは?

オープンソースとしてのKubernetesの特性はそのまま活かしつつ、AWSのマネージド・サービスとの連携を強化している。

  1. EKSはエンタープライズ企業が本番のワークロードを実行するためのプラットフォームであること
  2. EKSはネイティブで最新のKubernetesの体験を提供すること
  3. EKSユーザが他のAWSサービスを使う時、シームレスな連携を実現し不要な作業を取り除くこと
  4. EKSチームは積極的にKubernetesプロジェクトに貢献していくこと

Amazon EKSはKubernetes Certifiedを取得している。お墨付きですよ。

EKSを学ぶには?

何はなくとも、Getting Started with Amazon EKSが用意されているので、それを実施してみて、手で動かして学んでみましょう。

手順の内容は以下の通り。

  • Amazon EKS サービスロールの作成
  • Amazon EKSクラスタ用VPCの作成
  • kubectlのインストールと構成
  • heptio-authenticatorのインストール
  • EKSクラスタの作成
  • Amazon EKSのためのkubectl configuraltion
  • Workerノードの起動と構成
  • アプリケーションの起動

VPCの作成なども、専用のCloudFormationが用意されているので、合わせて実施してみて欲しい。そんなに苦労なくできるはず。

EKSのネットワーク周辺機能

IAM Authentication + KubeCtl

EKSの特徴は、AWSリソースとの連携。権限周辺の制御で重要なIAMに関しては、以下のフローで制御される。

AWS IDはRBAC(Role Base Access Controll)で認可され、K8sの各アクションの認可をする。そこで利用されるモジュールがheptio。

ネットワーキング基盤として、CNIの活用

EKSはCNIに準拠。CNIプラグインによるネイティブVPCネットワーキングに対応し、複数のPodはVPC内に存在するようにPod内に同じVPCアドレスを持つ。

GitHub上で公開されているので、気になる方は是非参考にしてもらいたい。

AWSの記事も公開されているので、合わせて参照されたい。

TigeraのCalico対応

Kubernetesのネットワークポリシーによってネットワーク・セキュリティルールを強制。CallicoはネットワークポリシーAPIの実装をリードしており、CNIプラグインと連携し、きめ細かなネットワークポリシーを提供。これにより、Kubernetes APIを使用してマイクロサービス単位でアクセス制御を実現可能。

ロードバランサー

AWS ALB IngressコントローラーをAWSがサポート。ALBの機能をIngressリソースを通じてKubernetesへ公開。L7ロードバランシング、ホスト名またはパスによるコンテントベースのルーティングをサポート。

サービスディスカバリ

ExternalDNSへコントリビュート、K8s Incubator project。

  • KubernetesサービスとIngressをAmazon R53オートネーミングサービスレジストリに登録
  • Amazon R53へのシンプルなDNSクエリを通じてKubernetesとAmazon ECSクラスタを横断してサービスディスカバリーを有効化
  • VPC内またはパブリックでのサービス実行をサポート

ログの集約

Fluentdを通じてCloudwatch Logsにログを集約可能。

濱田感想

EKS全くのド素人で、GettingStartedをこの間やってみたばかり(参考:【まずは触って体験】リリース直後のAmazon EKSでサンプルアプリケーションを動かしてみた)だったのですが、知らない要素が多くて、すっごいためになりました。

まだCNIやCalicoあたりを触れてないので、Kubernetesをあれこれいじってみながら、どんどん知見をためていくための良いきっかけになりますね。

講演の中では、今東京リリース前であっついFargateや、Codeシリーズの紹介もあり、DevOpsスペシャリストという役職の厚みを感じさせるてんこもりの講演で楽しかったです。今後も、Blackbeltなど、要チェックでございます。

FiNCを支えるインフラ技術 〜ECSとDevOps〜

講演者は、FiNC社の中村 郷史さん。

なぜECSにしたのか?

  • スケール性能
    • コンテナ(サーバ)増速の速さ
  • リソース最適化
    • 1台のサーバリソースを使い切れる
  • 多様な構成管理、異なる設定管理
    • SREが中央管理するのではなく、開発側に移譲

発表内容の全体像はこちら。

デプロイフロー

DBのマイグレーションのデプロイフローはこちら。

DBのマイグレーションは、utilityクラスタのコンテナの中でサービスを更新し、画像アップロードとDBマイグレーションを実行。その後、Applicationクラスターを更新する流れとなっている。

テストフローはこちら。

GitHubへのコミットを起点にイメージからコンテナを起動。必要パッケージをインストールし、db create後にテストコードを実行。

ここで環境構成をチェックする方法を導入。対象ファイル、ディレクトリ全体をSHA256に変換。インストールにDockerfile、Gemfile、マイグレーションにdb/migrateを利用。

改善版のテストフローはこちら。

config checkを導入することでディレクトリやファイルの整合性の検証を実施している。

オートスケール方法

ECSのスケールイン/アウトの方式がこちら。

unicorn worker numでメトリクスデータをNew Relicに送信。そこからLambdaでメトリクスを取得しその情報をCloudWatchに送信し、スケールイン/アウトのトリガーが発動される。

EC2のスケールアウト方式がこちら。

こちらでは、EC2のCPU利用率をCloudWatchで監視し、LambdaからCloudWatchを確認し、EC2のdraining/terminateを実行している。

バッチ処理

バッチ処理には、Jenkinsを利用。ジョブの制御には社内自家製ツールを利用しており、そこからタスク定義の検索、リポジトリ検索、docker pullからのコマンド実行を実施している。

fluentdの構築

awslogsではなくfluentdを使っている主な理由は、コスト面。プロダクション環境で吐き出されるログの量から計算すると、月10000$を超える計算となり、fluentdを使うこととなった。

fluentdに障害が発生したときに、コンテナが起動しない問題があった。原因は、fluentdのAggregatorで全アプリケーションの全種類のログを受けておりSPOFになっていたため、一度Aggregatorに障害が発生したときに、コンテナ起動時にその通信ができないことでコンテナが起動しないという事象が発生した。

改善例がこちら。

各コンテナインスタンス内に1つずつfluentdのクライアントコンテナを導入。そこから、各ログ種別にわけたfluentdAggregatorに分けて送信することで、SPOFを回避した。

ワーカーの監視方法

非同期処理を実行しているワーカーが処理中にコンテナが停止してしまい、最初から処理を再開する事態が発生。ECSタスクの停止動作には、以下のコマンドを利用していた。

$kill -SIGTERN (kill -15)
$kill -SIGKILL (kill -9)

改善点として、以下の停止シグナルを送ってから、停止するまで待つようにした。

$kill -USR1

このため、コンテナ監視環境を社内で構築した。ワーカーの監視方法がこちら。

稼働中のタスクの最大メモリとワーカー数を確認、SystemsManagerにメモリとワーカー数を問い合わせ、最大メモリ値を超えたタスクに対して、上述したユーザ停止シグナルを送りタスクを終了させる構成とした。

濱田感想

ECS運用に関する活きたTIPSが満載で聞いていて非常に楽しかったです。アプリケーションはRailsで構築されていたかと思うのですが、普段のDevOpsの文脈ではあまり話題にあがらない(?)DBマイグレーションの話があったり、最後のワーカーの監視方法などは独自性が強く、興味深い点でした。

実運用しているならではのTIPS、貴重ですね。似たようなシチュエーションで困ったときには参考にさせてもらいたいなと思いました。

AWS初学者がDevOpsツールを作ってみた

講演者は、株式会社ビズリーチの渡部未来(ABAB↑↓BA(@ababupdownba)さん。

ビズリーチについて

いわゆるひとつのこれの会社です。最近みなさん、よく見ていただいているかと思います。

SRE/インフラエンジニア絶賛募集中です。

SRE/インフラエンジニア(HRMOS) | 株式会社ビズリーチ

どしどし応募くださいませ。

アジェンダは以下の通り。

  • Elmの紹介
  • HRMOS採用管理のサービスアーキテクチャ
  • HRMOS採用管理の開発における問題と対策
  • 自分に何ができるか
  • Panopticon
  • まなび

Elmの紹介

面白いからやってみて(断言)

ElmはWebアプリケーション(フロントエンド)を開発するための言語。AltJSで、言語がフレームワークを内在。関数型で型安全機能もあり、高い生産性を誇る。

HRMOSのアーキテクチャ

アーキテクチャはこちら。ECSアプリケーションとしては非常に一般的な構成かと思います。

ステージング/本番環境の構成はこちら。

開発環境では、インスタンスにSpotFleetを使用して、コストを抑えています。

ECS利用の規模感は以下の通り。

  • サービス(モジュール数):35
  • タスク数:54
  • コンテナインスタンス:29

HRMOS採用管理の開発における問題と対策

検証のため、PullRequest毎に環境のサブセットを作って機能テストを実施。

これには、問題があった。各チケット単位(プルリクエスト)で環境のサブセットが用意されているため、あるはずのモジュールがなかったり、テストがうまくいかない時に環境の存在確認に時間がかかったり、無駄に手間が増えていた。

SREチームでも、Sandbox環境を提供してくれたり、積極的な権限付与をしてもらったり、AWSコンソールツアーを実施してもらったりした。

そこでElmを書きたくなった。

AWSにはいろんなコンポーネントがあって誘惑が多い。そこで。自分の得意分野(Elm)で勝負しようと思ったのがきっかけである。その後、ECSをひたすら勉強して出来上がったのがPanopticonである。

Panopticonとは?

  • Lambdaでboto3経由で、ECSの情報を取得
    • API GatewayやデプロイやServerless Frameworkを利用
  • S3でElmの生成物(index.html + bundle.js)を配信

そうして出来上がったのがこちらの画面です!是非雰囲気を感じてください!

今後、以下の展開を検討中。

  • Panopticonを用いた、開発者向けECS講習の実施
  • (需要があれば)OSS化
  • サービス化?
  • KubernetesやGCPにも対応?

今回の開発における学び

  • AWS超楽しい
  • 得意分野と合わせることで苦手分野は克服できる!
  • 新たなキャリアは自分で切り開くもの!
  • 他のメンバーを苦手分野に巻き込む理由雨ができる!
  • 新しいことをスパルタ式でやると圧倒的成長が!

濱田感想

めっちゃ聞いていて面白かったです。はい。Elmとかは正直全然しらなかったんですが、AWS経験がほぼない初学者の状態から2週間ほどでここまで作り上げる圧倒的スピード感には、会場全体が驚いてましたね。

出来上がったPanopticonの動画も是非見てみてください。皆さん、普段ECSのコンソールを使っていて辛さを感じたことないでしょうか?自分はありますw。ある程度触りまくってみないと、クラスタ、サービス、タスク、コンテナインスタンスの階層構造を掴むのに苦労するんですよね。特にクラスターとサービスの関係は慣れが必要だった記憶があります。

もちろん、AWSコンソールには必要なオペレーションをすべて含めて置く必要があるのでUIが一筋縄ではいかないのは理解しているつもりですが、Panopticonは、クラスターとサービスとタスクの包含関係が非常に直感的に表現されていて、わかりやすいんですよね。

一番最初、ECSを触り始めたときの「構成をイメージすることの難しさ」に対して、非常に便利なソリューションかと感じました。

OSS化も視野に入れている(?)とのことなので、正座で待機しようと思います!

(おまけ)講演中のツイート群

当日の会場の雰囲気は、以下のツイート群から察してください。

Elmとか初耳でした。

EKSにシュッと入門

講演者はエウレカの坂田 純さん(sakajunquality@sakajunquality)。

k8sのエウレカ社での利用状況

  • 5クラスター存在
    • うち4つがGKE
    • 1つがEKS(絶賛検証中)
  • アプリケーション種別
    • ML Recommend Model
    • Moderation Microservice
    • Slackbot
    • Redash
    • Spinnaker

マネージドなk8sについて

現状、これだけのマネージドなk8sが存在している。

  • Google Kubernetes Engine
  • Amazon EKS
  • Azure Kubernetes Service
  • Oracle Container Service
  • IBM Cloud Kubernetes Service
  • etc...

とまぁ、世の中いろいろあるんですが、自分はGKEとEKSしか触ったこと無いので、GKEと比べつつEKS入門な感じで進めていきます。

(このあとは、k8sの各コンポーネントに対して、GKEとEKSでどのように作業していくのかが、詳細にまとめられています。GKE使っていた方も、今回のGAで初めてEKS触ってみた方も必見の内容です)

濱田感想

EKSしか知らない自分にとっては、知らないGKEの世界が垣間見えて面白かったです。そもそもk8sについても知見が殆どないんですが、k8sに準拠(certified)していても、微妙に異なる点がいろいろあって興味深い発表でした。

自分はAWS事業部所属ということで、そもそもGCPを触ることが殆どないんですが、たまには他のパブリッククラウドの実装も垣間見ながら共通点と相違点を抑えておくのもいい勉強になるんでしょうな。エンジニア道は険しい。

まとめ「コンテナ界隈、あっちあっちやで」

ごっつ適当にまとめた感が強いけど、まさにそんな印象でした。アプリケーションホスティングの手段として、コンテナはもはや無くてはならない存在だし、知見もたまりプロダクション環境での利用もかなり一般化している印象です。

先日は、こちらにもお邪魔させていただきました。

まだコンテナ様子見という方も多いと思いますが、開発環境でも手軽につかえるし情報も非常に多いので、まずは一歩踏み出して触ってみると良いのではないでしょうか。自分も、最近ECSやFargate触ってて凄くたのしい限りです。そのうち、LTなり登壇もしてみようかと目論見中。

また、コンテナ支部では、次回Fargate入門も予定されております。7月日本リリースが予定されているFargate、一緒に学んじゃいましょう。運営の皆様、いつもありがとうございます。

それでは、今日はこのへんで。濱田(@hamako9999)でした。