AWS Summit Tokyo 2019に参加した話

AWS Summitに初参戦

表題のとおり、AWS Summit Tokyo 2019に参加してまいりました！
３日目だけなのですが、色々と勉強になったのでよかったです！
参加したセッションは以下です。

• 基調講演
• メルカリ写真検索における Amazon EKS の活用事例
• Kubernetes on AWS（Amazon EKS実践入門）
• EKSで構築するグリーのエンターテインメントシステム
• めざせ！サーバレスプロフェッショナル

その中でのお話をかいつまんで書き連ねていこうかと思います。

現地到着〜基調講演

入場までのみちのり

今回は開催地は幕張メッセだったので、私の自宅からは３０分ほどでした。
着いて早々エスカレーターが２ボトルネックになっており（２基しかない…）、人が溢れていました。笑
改札から出ると人がいっぱいでこの時点で帰りたくなりましたが、暑い中頑張って幕張メッセまで歩きました。
幕張メッセついてからも入口が一番西側だったので結構歩きました。

基調講演

入場後はそのまま基調講演の会場へ向かい着席して小休止していると、基調講演が始まりました。
副社長のMarco Argenti氏のお話
まずはお決まりのAmazonの歴史ってこんなのだよ、というところから始まりこんなんやっていきたいね！的な話でした。
次に株式会社メルカリ様のCTOである名村 卓氏がこんなサービス使っています、こんなことやりたいです的な話をしておりました。
が、途中で腹痛に見舞われリタイヤ…体調は整えておかなければなりませんね…。

基調講演に関してネガティブな感情を持たれている方はいらっしゃると思いますが、やはりあれだけ大きい企業の経営陣の話を本人の言葉で直接聞けるのは得るものが非常に大きいと思いますので私は参加をおすすめ致します！

メルカリ写真検索における Amazon EKS の活用事例

メルカリ様でSREとしてご活躍されている中河 宏文氏から、メルカリではどのようにしてEKSを活用されているのかを伺えました。
基調講演で名村氏も触れられておりましたが、いわゆる画像検索の機能ですが基調講演で触れるほど温度感高めに取り組まれているのだと思いました。

Lykeionというメルカリ様内製のプラットフォーム上に写真検索機能を実装しており、以下のような機能を利用されているようです。

• Training / Service CRD&カスタムコントローラー
• コンテナベース・パイプライン
• Training / Service コンテナイメージ・ビルダー
• モデル・レポジトリ

コンテナベース・パイプライン

AWSとGCPのマルチクラウドで構成されており、その中のTraining KuberunetesクラスターというものをEKSにて運用しているそうです。
細かい部分は理解が誤っている可能性もあるので割愛しますが、Training custom resourceというデータ群を作成するのにコンテナベースのパイプラインを採用しています。理由としては下記です。

• バッチをHourly / Daily / Monthlyで実行しているため
• 工程毎に違うコンテナで利用しているため（ライブラリ依存などがあるため）
• パイプラインをyamlで記述 / 管理できるため
• 各工程の入出力結果も永続ボリューム（EBS）を介して管理しているため

また上記のバッチ実行情報をKuberunetesのCRD上で管理できるため、障害原因の探索や復旧処理の再現性も容易なためKubernetesは維持・運用において非常にパワーを発揮しているとのことでした。

S3上のイメージストア

S3上に画像検索の元となるイメージ群が置かれており、Training custom resourceをインデックスする際にはそれらを持ってこなければいけません。
当然画像数が多く、処理の重いジョブになります。
上述した永続ボリュームであるEBSに一定期間キャッシュさせることで、ダウンロードにかかる負荷を軽減させるアーキテクチャー構成になっています。

EKSのメリット / デメリット

メリットとしては以下です

• 柔軟性が高いため細かいカスタムが効く
• 当然ながらAWSサービスとの連動性が高い

デメリットとしては以下です

• マネージド型サービスではあるがKuberunetesの知識が必要

所感

マルチクラウドをうまく使い分けているなぁ、と感じると同時にやはりAWSだけではだめだなと痛感させられました。
エンジニア的な観点からの選択過程や意思決定となるポイントなど非常に勉強になりました。

GCP部分の話などまるっと割愛しているので、よろしければご本人の発表資料を見ていただけるとわかりやすいと思います。
メルカリ写真検索における Amazon EKS の活用事例

Kubernetes on AWS（Amazon EKS実践入門）

AWSジャパン株式会社様の河野 信吾氏が登壇されておりました。

EKSって何？

Kuberbnetesの運用において、コントロールプレーンが悩みのタネになりがち

• 運用中のバージョンアップはすごく大変
• コントロールプレーンの冗長化は必須
• なにかあっても誰も責任を取ってくれない

これらを解決するのがElastic Container Serice for Kubernetes (EKS)です。
EKSを利用することで以下が実現できます。

• コントロールプレーン運用からの解放
• セキュアなコントロールプレーンを実現（シングルテナントで稼働）
• AWSマネージドサービスとの連携が容易
• 容易なノードの選択

活発なコミュニティ

Kubarnetes自体かなり活発なコミュニティですが、AWSもより便利にするため様々なものをリリースしています。
以下は一例です。
ALB ingress controler
KuberunetesのコンテナへのルーティングをALBで捌く際にプロビジョニングしてくれるツールです。
AWS EKS Cluster Controller
クラスターの実行環境やコントロールプレーンとデータノード間をマネジメントできるツールです。
CloudWatch Container Insights
コンテナだけでなく、ノードやポッド、名前空間からサービスレベルまでCloudwatchに集約してダッシュボード等で利用できるサービスです。

まとめ

EKSは怖くない！簡単なのでぜひ試してみてね！
Previewの機能もガンガンつかってレビュー欲しいな！
って感じでした！（EKSはお金が怖い…。）

EKSで構築するグリーのエンターテインメントシステム

このセッションはグリー株式会社様のインフラストラクチャ部にてリードエンジニアをされております堀口真司氏から、グリー様がどのようにしてEKSを利用するまでの道のりと現在の活用法を伺うことができました。

EKSまでの道のり

Dockerの利用

Dockerが流行りだした2014ごろから利用開始したものの当時はあまり流行らなかったそうで…理由としては以下になります。

• 手元のPCでは使い勝手が悪い
  非Linuxの場合にはdockerの実行自体にVMが必要になり起動があまり早くないため、Dockerのメリットを享受できなかった
• サーバー側での設定が困難
  上述のことから直接コンテナに入ることや、ネットワークの設定が非常に煩雑だった
• 本番ワークロードで利用する場合は何かしらのオーケストレーションツールの導入が必須
  Dockerを管理するためのマネージドサービスがなく、Kubernetesなどはまだ学習コストが高い割に実運用している事例が少なかったため手を出すのをためらった。

使ってはみたものの、思った以上に手間がかかったというのが主な理由だったようです。

ECSの利用

上述の手間を解消させるマネージド型サービスとして登場したのがECSで、現在においてもグリー様は活用されているとのことです。
ECSを導入し、コンテナ化が促進したことで以下の利益が得られたと発表されておりました。

• インフラ担当の負担を軽減
  コンテナ化することで開発チームに環境を管理させることができるため
• Optimized AMIがあるためセットアップが容易
  あらかじめDockerなどがインストールされたAMIがあるため容易に利用できるため
• オーケストレーションツールとしての使い勝手
  アップデートが頻繁にあるため日々便利になっていくため

Docker単体での利用で感じていた足りない部分を補うようなサービスで、非常に簡単かつ便利にコンテナを利用できるので重宝しているとおっしゃってました。

EKSの導入

ECS運用を通して、もっと細かく管理したいとの思いもありKuberunetesをEC2に導入して管理してみたが運用が非常に大変だったそうです。
以下の理由からKuberunetesを独自で管理するのは断念した経緯があったそうです。

• Kuberunetes自体の構築がすごく大変
• バージョンアップなどのメンテナンス作業も広範に渡り、影響範囲が大きい
• 異常時の対応やデバッグをコードから読み取って対応していく必要がある
• Kuberunetesで動くサービス自体は小規模でもクラスタの維持・運用がそれ以上に手間がかかる

EKSはマネージドサービスなので上述の問題を解消してくれた。
さらにメリットとして以下が挙げられていました。

• kubectlがそのまま利用できるための情報量が多く、使い勝手も良い
• EKSのコントロールプレーンを管理しなくて良いので安心

特にEKSのコントロールプレーンを管理しなくて良いという点に関しては非常にメリットを感じているそうです。
確かにコントロールプレーンに何かあると…というのは必ず挙がる問題だと思うのでそこだけでもEKSの恩恵は大きいのかなと思いました。

実運用

実際の運用はどのようにされているのか、という部分もお話しを聞くことができました。

イメージビルド

Jenkisを利用しており master / slave構成でコンテナを実行しているそうです。
ちなみにmasterは公式イメージを引っ張っているだけとおっしゃってました。（シンプルイズベストですね！）
コンテナは所謂Docker in Dockerでしており、ECRにPushするときは最新イメージをlatestラベルを付与してあげる運用をしているそうです。

デプロイ

Strategyは現段階で必要性を感じていないため特に調整していないため、一気にコンテナが入れ替わるといったデプロイ戦略を取られているそうです。
ユニークだなぁと思ったのが、Deploymentのannotationsに無作為な時刻を設定してDevelop環境のコンテナを一気に入れ替えるらしいです。

sample

spec:
  replicas: 2
  selector:
    matchLabels:
      run: hogehoge
  template:
    metadata:
      annotations:
        kubernetes.io/change-cause: "201906151845"    #Change here

モニタリング

モニタリングはこんな感じのアーキテクチャー構成（たぶん）

DeamonSetでfluentdを稼働させてログを集約 / フィルタリング / フォワードを実施して、その後CloudWatchLogsに送信している。
フィルタリングをかけることでCloudWatchLogsの料金を削減できるようにしている。
元々EC2にGrafanaを構築して利用していたようで、それをそのまま流用してダッシュボードにて管理している。
Node / Pod / Container毎にメトリクスを取得してモニタリングしているとのこと。

運用を通してEKSへの所感

• Kubernetesの知識が必須になるため、マネージドサービスといえど自分自身で管理すべき部分も多く出てくる。
  e.g.) NamespaceやRBACの存在、名前解決など
• 権限管理が煩雑
  IAMユーザーの権限がなくても、Kubernetesクラスタのadmin権限とかも持たせることができちゃう
• CLIのみでの操作
  現在はまだブラウザで操作できないので、もしものときが心配
• AWSリソースは一部標準で対応されていないのでAnnotationでの管理が必要
  e.g.) ALB / EFS
• コストが高い
  コントロールプレーンの管理に対するコストがかかる（HA用に3台EC2が必要とか）

まとめ

ECSとEKSを利用していて双方にメリット / デメリットがあり、そこをうまく理解して使い分けすることで十分な恩恵を受けることができる のではないかと思いました。逆にそこを理解していないと余計な運用が増えたり、コストが過剰に掛かったりが今まで以上に遥かに増えると思いました。

ECSの良きところ

• クラスタの管理に費用がかからない
• VPCネイティブなので既存のサービスからすぐに相互アクセスが可能になる
• マネコンからも操作ができて簡単
• Auto Scalingの設定も簡単
• IAMで権限設定するため今までの知識を流用できる

EKSのよきところ

• Kubernetesをインストールするのに比べ、遥かにセットアップが楽
• kubectlをそのまま利用できる
• 標準でAWSリソースに対応していない分、ロギングやモニタリングなどの選択肢が多い
• IAMとRBACが存在することで柔軟な権限管理が可能（煩雑ではあるが…）
• バージョンアップなどは圧倒的に楽

めざせ！サーバレスプロフェッショナル

AWSジャパン株式会社様の清水 崇之氏が登壇されておりました。
自称AWS芸人とのことで、普段は関西で働かれているそうでとてもお話しが上手でした。

サーバレスの魅力

• なんと言ってもサーバの管理が不要なこと
• アイドル時の待機費用削減
• スモールスタートが可能
• 使い慣れた開発環境で実施できる

AWS ToolitやAWS SAM CLIなど便利なツールもいっぱいリリースしているから使ってください！
早速SAMをインストールしてみました。

$ pip --version
pip 18.1 from /usr/local/lib/python3.7/site-packages/pip (python 3.7)
$ pip install --user aws-sam-cli
Successfully installed Flask-1.0.3 Werkzeug-0.15.4 arrow-0.14.2 aws-lambda-builders-0.3.0 aws-sam-cli-0.17.0 aws-sam-translator-1.10.0 binaryornot-0.4.4 certifi-2019.3.9 chardet-3.0.4 chevron-0.13.1 click-6.7 cookiecutter-1.6.0 dateparser-0.7.1 docker-4.0.1 future-0.17.1 idna-2.8 itsdangerous-1.1.0 jinja2-time-0.2.0 jsonschema-2.6.0 poyo-0.4.2 pytz-2019.1 regex-2019.6.8 requests-2.22.0 serverlessrepo-0.1.8 six-1.11.0 tzlocal-1.5.1 websocket-client-0.56.0 whichcraft-0.5.2
$ sam --version
SAM CLI, version 0.17.0

今度使って記事を書いてみよー

AWS SAM(Serverless Application Model)

AWS SAMとはAWSサーバレスアプリケーションを作成・管理するための機能です。

• 関数やAPI、イベントソースなどを簡単に記述可能
• 上記を利用してライフサイクルコントロールを実現する
• CloudFormationに対応するためのpackageとdeployコマンド

特に最後のpackageとdeployコマンドに関しては非常に便利です。
packageはSAMテンプレートをClaudFormationテンプレートに変換してくれます。
deployはCloudFormationが実行されて環境が作成されます。

SAMはざっとこんな感じで表記できます。

sample_get_request.yaml

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31      #Specify SAM Version

Resources:
  api_gateway_testFunction:
    Type: AWS::Serverless::Function        #Fixed
    Properties:
      CodeUri: s3://sandbox/index.zip      #Ran code path
      Handler: index.handler               #Ran function
      Runtime: nodejs8,10                  #Specify runtime
      Events:
        GetOrder:
          Type: Api                        #API Gateway added by implicit
          Properties:
            Path: /sandbox/{request_id}    #tail is path parameter
            Method: get                    #HTTP method

複数のCI/CDにおけるアカウント戦略

上記のサービスやCodeシリーズを利用することでAWSサービスでCI/CDを実現することが可能
しかしリソースの管理やセキュリティの観点から色々と考慮すべき事項が多い

うまくアカウントの運用も利用して、理想的な開発を実現することが可能だということでアカウント戦略にもふれられておりました。

同じアカウントでスタックを分ける

同じアカウントを利用するが、環境毎にスタックを分けて運用していくという戦略
小規模な組織や個人に向いている

メリット

• リソース管理の容易
• 管理や監視の統合が可能

デメリット

• アカウントへの許可やアクセスの分離が煩雑になりがち

アカウントを分ける

プラットフォームやチーム毎にアカウントを分けて管理するという戦略
大規模な組織や企業に向いている

メリット

• アカウント毎のリソース分離が容易
• アクセス管理が楽

デメリット

• 複数アカウント増えると管理が煩雑

インフラ外の部分で運用が煩雑になっている場合には、このような戦略を考えていくことも必要だとお話しされていました。

Tips

• Lambdaの環境変数
  SAMと環境変数を利用して同じリソースでも、環境毎にデプロイ可能
• Lambdaのバージョニング・エイリアス
  バージョン毎にエイリアスを作成できるため、Prd,Stgなどの異なるワークロードにて作業可能
• CodeDeployにおける段階的なデプロイ
  Gradual Code Deployment を利用して様々なデプロイコントロールが実現できる
• AWS CodeStarを利用してCI/CDのテンプレートを作成
  AWS Codeシリーズをかき集めたようなサービスでCI/CDのテンプレート化が実現できる
• sam local start-apiでローカル環境でAPIテストができる
  上記コマンドでローカルポート：3000を利用して疎通

まとめ

めちゃめちゃ濃い内容のセッションだったので、全然書ききれませんでした…。
7月1日から公開されるようなので、ぜひ見ていただきたいセッションです！

企業ブースとその他

様々な企業様がブースを出店しておりました。
その中でいくつか気になったサービスをピックアップします。

Sumo Logic

最近ちょくちょく聞くなーと思っていましたが、ブースがあったので中の人に色々と聞いてきました。
ざっくりとこんなかんじです。

• 導入カンタン
• ダッシュボードかっこいい
• 今ならお試し30日間無料

機会があれば使ってみたいな〜と思いました！

CircleCI

言わずと知れたCI/CDツールですね。
こちらも気になっていたので色々と聞いてきました。

• .com版のGithubならぜひ一度使ってみてほしい（１コンテナなら無料だよ）
• Jenkinsとの比較ならサイボウズさんのスライドが秀逸
• 脱Jenkinsおじさん

AWSブース

サービス毎に別れていて、そこにいる方は本当の中の人たちです。
困りごとや要望など色々とコミュニケーションがとれました。
またエキスパートになんでも質問できるコーナーがあったので、困りごとを相談させて貰いました。
色々と聞けて月曜からの業務に早速活かせそうです！ぜひ機会があれば行ってみてください。

ちなみに認定者ブースはまずまずの混み具合だったので利用しなかったです。

総評

メリット

• モチベーション爆上がり
• ノベルティいっぱい
• 細かい疑問が解決
• 思いもよらぬひらめき

デメリット

• 人酔いするくらい多い
• セッション予約しても必ずしも座れるとは限らない

結果的に行って大正解でしたー
来年は5月12日〜5月14日にパシフィコ横浜で開催が決定しているので、ぜひタイミングがあえば参加してみてください！