ゼネラルセッション

AWS の中の人の話

AWS Loft tokyo ask an export ということで常駐しているソリューションアーキテクトに質問できるコワーキングスペース。

AWS Innovate オンラインイベントを同時開催中で、多くのセッションを用意。

• AI サービス: 機械学習のモデルなどの AWS 側で全て用意されており、SaaS サービスとして利用可能。
• ML サービス（SageMaker）: 機械学習を行うための環境を提供。

オペレーション、アーキテクチャ、Develop-frist な開発フロー、セキュリティ、データの５つ。

• 価値を産まない作業をオフロードすべてを自動化。

• マイクロサービス、疎結合、イベントドリブン

• 自動化。

• 自動化。継続的なセキュリティ評価。

• 目的に即した DB の選択。

• AWS Fargate EKS ECS: コンテナ技術

• AWS Lambda: サーバレス

最後に一言。開発者とクリエイターの間の隔たりを縮める。 On Builders and Dreamers

まつもとゆきひろ, Matz

けっきょく、生産性に寄与できる技術を選択することが一番。 例えば、静的言語と動的言語でも生産性が上がる局面が異なる。

どの技術を採用することで生産性が上がるのか？ 背景・制約条件を考慮する。チームが抱えている問題を理解して、それを解決するためにどの技術が最適であるか判断する。

判断を人に任せない。判断を人に任せない環境を作る。

Tumble Weeds にならず、どういうふうにすると生産性を向上させられるか判断し、 最新の技術に振り回されないようにする。必ず、選択理由を持って技術を採用する。

• 風を作る（トレンドに振り回されるのではなく、作る）
• 主体性（事態が自分のコントロール化にある環境にする）

ソニックガーデン - 倉貫

やらなくてはいけない条件から、どの技術を選択すべきか考えるべき。

トークセッション

HackerNews, reddit

第 1 回 AWS Fargate かんたんデプロイ選手権

AWS Fargate とは？

実行環境 EC2 インスタンス運用業務

• OS, Docker Agent, ECS Agent へのパッチ当て・更新。
• 実行中のコンテナ数に基づく、最適なリソース使用率を保つための EC2 インスタンス数のスケーリング

仮想マシンとコンテナ内の管理をユーザがやらないといけない。 → 差別化を図れる業務ではないので、めんどくさいし、非効率。

AWS Fargate

• AWS 側が仮想マシンを管理してくれる。EC2 インスタンスを選択する必要がない。パッチ当てやスケーリングを AWS が勝手にやってくれる。
• AWS サービスとの連携（セキュリティグループや IAM が使える。VPC ネットワーキング（コンテナに対して VPC フローログなどが使える）、ELB、CloudWatch など）

AWS を使ったコンテナのデプロイ

• Task Definition(register): アプリケーションの実行に必要なコンテナ類を定義する。

• Cluster(create): クラスタはアイソレーションの境界。IAM パーミッションの境界。

  • Task(run)タスク定義からタスク（Pod）を実行する。
  • Service(create): 常駐するシステム。ELB と連携。

aws ecs のコマンド

• run-task
• craete-service

Fargate CLI

nginx を動かす。

• ポート 80 番を開放したセキュリティグループを作る。
• タスクを実行する。
• fargate コマンドを使う。

コンテナの削除

常駐するシステムの動かし方

CLI ツールは２つある。

• awslabs/fargatecli

• turnerlabs/fargate: こっちのほうが運用向き？

• AWS アカウントにデフォルトで存在するリソースを利用 デフォルトの VPC を使っている。

• ユーザ自身で作成：セキュリティグループ

• Fargate CLI による自動作成：ECR リポジトリ、ECS クラスタ、ECS タスク実行 IAM ロール、タスク定義、ECS サービスの定義

Pros

• 勉強する上でどのようなリソースを作らないといけないのか、概要を理解しやすい。
• --verbose を使うと、中で何をやっているのか、ログで確認することができる。
• とにかく簡単。動きを見るには最適。

Cons

• 本番環境で使うには、ちょっとアドホック（過度に抽象化されすぎている）。
• IaC や CI/CD パイプラインについてのもう少し考えて環境を作りたい。

AWS Fargate に対応したデプロイツール

構成例：ALB -> ECS on Fargate -> RDS Aurora

• ECS 以外のリソースをどのように作成・更新するのか？
• ECS サービス更新時にタスクが正常に起動しない場合、ロードバランサーのヘルスチェックが失敗して、サービスインできない場合とか。

Awesome-ECS: いろいろな情報がまとまっている。

• AWS CLI
• ECS CLI
• AWS CloudFormation
• TerraForm
• AWS CDK
• ecs-deploy
• ecspresso

各デプロイツールの背景を読み解く

AWS CLI

• 新サービスに全て対応している。

• AWS API の呼び出しパラメータをほぼ全て利用可能。

• CI/CD パイプらいの実態がシェル芸になりがち

• リソースの遺贈 k 難経をコマンドの実行順に反映させる必要がある

• ロールバックを想定したスクリプトを書こうとすると複雑化しがち.

ECS deploy

• AWS CLI よりこなれている。

• 自前でシェルスクリプトよりは安全。

• 周辺のリソースの管理ができない。

ECS CLI

• Docker Compose 定義ファイルを利用した ECS サービスの作成・更新に対応しているため、ローカル開発と親和性高い。

• ECS 以外のリソースを管理できない。

• ロールバックの機能がない。

CloudFormation/Terraform

• 1 つのツールですべてのリソースを管理できる。

• ファイルを見れば、バージョン管理で変更履歴を追える。

• 変更差分を見ることができる。

• AWS リソース間の依存関係も考慮できる。

• 更新できないリソースの場合、新規作成してから古いリソースを削除するようになっている。

• AWS リソースそれぞれについて十分な理解が必要。

• 最新の API に対応していないことがある。

• VPC やデータベース、Fargate タスクのようなライフサイクルが異なるリソースの管理方法を考えれる一定のスキルが必要。

AWS CDK

• 単体テストができる。

• 裏で CloudFormation を使っている。

• 抽象度が高いため記述量が少ないが、意識していないと。

VSCode の IntelliSense で ECS タスクの保管ができる。

マルチテナント時代におけるテスト・ベストプラクティス

マルチテナントの基本

ここでは、マルチテナント = SaaS とする。

マルチテナントテストの基本

以下の２点についても考慮すべき。

• パフォーマンステスト: 参照、更新テスト、レイテンシー（UI/UX）、スループット（処理件数）、限界性能テスト、耐久テスト
• セキュリティテスト: ブラックボックステストだと調査が大変。グラスボックステスト：テストの誤検知を避ける。

マルチテナントテストのベストプラクティス

ソフトウェア開発者のための AWS 環境構築フレームワーク AWS Cloud Development Kit (CDK)

CLI/SDK

• API コールが失敗したら何が起こるのか？
• どうやってアップデートするのか？
• リソースが準備完了なのはどうやって作るのか？
• どうやってロールバックするのか？ → 状態を定義しているわけでじゃないところが問題。

プロビジョニングツール：CloudFormation/Terraform

• 状態の定義
• 再生性可能
• ツール固有の記述方式
• 抽象化がなく、YAML でかかないといけない。詳細な記述が必要。手間がかかる。

Document Object Models (DOMs）

• プログラミング言語として設定を定義する。
• CloudFormation を作るためのツールなので記述量が多いのが難点。

AWS CDK

• あるべき状態の定義がコードで生成可能（CloudFormation のテンプレートがコードから生成できる）

• AWS のベストプラクティスが組み込まれたライブラリを活用して、少ないコード量でき術可能。

• オープンソースで開発。

• TypeScript（GA）

• Python（GA）

• Java

• C#

JSII JavaScript で書かれたクラスに他の言語からアクセスするためのライブラリ。

• AWS が CDK 実装のために開発し、オープンソース化した。
• CDK は TypeScript で実装され、jsii によって多言語対応を行っている。

CDK の特徴

• 一般のプログラミング言語を使える（TypeScript だと型チェックもやってくれる、デプロイの失敗を減らせる）。
• クラスなどの抽象化の概念を使える。
• エディタによるチェックが使える。強力！
• コード量が少なくて済む（ベストプラクティスに沿ってうまいことやってくれるから）。
• テストコードが書ける！メンテナンス性に優れる。
• スタック間の依存関係が記述できる。

AWS CDK の使い方

CDK デプロイ管理用の環境（S3 バケット）を作る必要がある。

CDK のインストール

現在、アップデートの頻度が高い状態にある。

• AWS CLI
• npm install -g aws-cdk

使い方

• cdk bootstrap
• まずは、cdk initで、サンプルコードをダウンロードできる。
• デプロイ：cdk build, cdk synth, cdk deploy
• テスト：サンプルにテストも含まれている。
• sdk diffで差分を見ることができる。

CDK のコンセプト

• App: CloudFormation テンプレートの生成とデプロイに利用する最上位要素
• Stack: CloudFormation Stack 苦い投資、デプロイ可能な最小単位。
• Construct：AWS CDK アプリの基本ビルディングブロック。

AWS Constructs Libraries

• High-level construct: 抽象化して書ける。コード量減る。デフォルト値や便利なメソッドを定義した AWS リソースを表すクラス
• Low-level construct: これで細かくパラメータ指定もできる。
• Patterns： High-level よりも抽象的。一般的な構成パターンを事前に定義したもの。

CDK DiveDeep

CDK テストコード

• ブログ: Testing infrastructure with the AWS CDK
• スナップショットテスト：あるべき CloudFormation テンプレート全体を用意し、CDK で作成したテンプレートが一致することを確認(Regression テストに有効)。
• Fine-grained テスト：リソースが特定のプロパティを持っているかどうかチェック。
• バリデーションテスト：単体テストと同じ感じ。誤ったパラメータを振ったときにエラーになるかどうかとかチェック。

CDK 複数スタックの管理

• スタック間に Construct を参照すれば OK。
• スタックの依存順序が定義可能。中でうまいこと依存する順番にエクスポートされるみたい。

CDK のアクセス許可の与え方

• D3 や DynamoDB などアクセス対象となる Construct はアクセス許可を与えるための grant から始まるメソッドを持つ。IAM ロールが作成される。

CDK のパラメータ

• Environment: CDK を実行するための環境変数（すでにあるリソースを変更するためには、ID を使う）。
• Context: CDK を実行するときの状況を JSON(ID の情報などが記載) で持っておく。他の環境でも再現性が担保されるようにするために必要。
• SSM ParameterStore: 既存 VPC に DB 接続情報を持つ Fargate を立てる。

AWS CDK の情報源

• ワークショップ: https://cdkworkshop.com

AWS の「隙間」を埋める隙間家具 OSS 開発

隙間の多いマネージドサービスをどう使うのか？

パッチ適応やバージョンアップなどの運用コストを払えないので、多少不便でもマネージドサービスを選択して、 後日の機能拡張を期待しつつ運用の手間を減らしたほうがよいのでは？

小さく、そのユースケース内で適切な汎用性を持ったものを作る（隙間を埋めるツール）。 → マネージドサービスでサポートされるようになったら、隙間ツールを捨てる。

隙間ツールを作るときの注意点

• 複数のサービス間連携を一度に処理するとリトライが辛い。
• 単機能に特化しつつ、そのドメインで汎用性をもたせると使い回せる。
• マネージドサービスができたときに簡単に取り除けるように。

設計をどうするのか？

• スケーリングの問題を解消するためにも、RDS などのスケールがしづらいサービスを避けたほうがよいかも。
• データのイベントドリブン処理は実装が楽。
• 状態はマネージドサービスに持ち、状態を持たない処理だけを書くとスケールしやすい。

フロントエンドエンジニアが K8s エンジニアになるまでの 10 年間を振り返る

「会社の要請」と「興味」のズレが転職を繰り返すことで解消されていった。 どこで何をやりたいのか、何が求められるのかから逆算して戦略的に動く、作る、話す。

• 軸を見つける
• アウトプットを続ける（GitHub、ブログ、OSS の翻訳などで書いてみて作ってみてわかることを積み上げる）
• 趣味と仕事を結びつける（やりたいことと要請のギャップを無理やり埋める。）
• 価値を高める（OSS 開発、登壇してプレゼンすることでプレゼンス向上、英語による発信）
• ギャップを見つける（できそうでできないことを見つける）。
• とりあえずやってみる（問題提起したり、自分で POC を作って公開する）。

40 分でわかる DynamoDB での App 開発

DynamoDB とは

• メンテナスンスフリー（セキュリティ、可用性、拡張性などを AWS をが勝手にやってくれる。開発者が管理しなくて OK）

Table 構造

• Table, Item（レコード？）, Attributes(カラムの相当)、パーティションキー（プライマリキー）、ソートキー（Index ぽいやつ）
• パーティションキー、ソートキー以外は、Attributes に値が入っていなくても OK（例えば、仮登録して状態で値がないという状態を作ることも可能）。
• パーティションキーとソートキーの複合キーとしてデータの検索が可能。
• NoSQL Workbench for Amazone DynamoDBで、データモデリング・コードの確認などの操作を簡単にできるようになる（Python, JavaScript のコードを出してくれる！！）。

アプリを作るときは

動画コメントをつけるチャットアプリの要件

• コメントの書き込み
• 25 検の最新の情報を取得。
• 全てのコメントを取得。
• 位置を指定して取得

API Gateway - Lambda - DynamoDB → Chalice を使って簡単にできる。

書き込みに対してスケーラブル。

• name(PK), time(SK), comment, chat_room
• GSI（グローバルセカンダリーインデックス）: name, time(SK), comment, chat_room(PK)

書き込みに対して、負荷をかけない設計が可能。 DynamoDB Stream でキャッシュして読み込みにかかる負荷を低減できる。 全文検索をしたい場合も、Elasticsearch との連携も可能。

キャパシティユニットの消費がどうなっているか監視したほうがよい？

• ScanIndexForward=false => 降順で Select する。

単純なキーバリューで表現できない用に見えても、クエリを使いこなすことで複雑なデータ取得が可能になる。

Lambda - Redis/DynamoDB streams の組み合わせ

CI をどうするか？

• CodeBuild であれば、IAM ロールを付与できるので簡単。
• DynamoDB localというローカル環境でテストすることができるツールも提供されている（課金の心配がない、Jar ファイルかコンテナの提供がある）。
• CodeBuild, CircleCI, GithubActions でそれぞれ同じテストを実行するサンプル紹介。

補足

Chalice は、API Gateway ＋ AWS Lambda for python の API 環境を実行するサーバレスフレームワーク。 代替するものに、Serverless Framework などがある。

Redis vs DynamoDB

• DynamoDB なら、データの永続化が担保されている。データの一貫性を付与することも可能（パフォーマンスの低下が起こるが）。
• Redis の場合、インメモリキャッシュになるので、読み込み速度が早い。データが消えてもいいケースではこっち（セッション情報など）。

Durability と Response のバランスに合わせて選択。