JAWS DAYS 2019に行ってきた

ランチセッションも含め、懇親会まで7時間ほぼ休みなしのセッション！ 午前は多少空席あったけど、午後はほぼどのセッションも満員で立ち見が出るくらいの大盛況。

スライドはここのページにまとめてくれています（多謝）

https://qiita.com/hayao_k/items/91c19480948f26b71705

子育てで覚える AWS Organizations 〜ITエンジニア英才教育〜

AWS Organizationsのセッション。 子供にAWSを使って自由に勉強させるというシナリオで、AWS Organizationsを紹介。 AWSアカウントをポンと渡したいけど、クレカの情報は渡したくない。 IAMだけ渡すとAWSを自由に使ってる感がない Organizationを使って事由に操作させつつも制限をかけたりトレースできるようにする方法。

• AWS Organizationsを使うと、カードなしでAWSアカウントが作れる
  • カードが登録されてるアカウント（マスター）は必要
• 組織は階層化でき、徐々に権限を狭めていくようなことも可能
• マスターの組織から、子の組織で利用可能なマーケットプレイス商品をフィルタリングできる
• Cloud Trailを使うことで、子の組織のアカウントで行われた操作をトレースできる
  • マスターの組織からでないとCloud Trailを無効にできないので、こっそり操作するようなことは出来ない
• Resource Access Managerを使うことで、親子のオーガニでVPCのサブネットを共有できる
  • 使いどころとしては、一家で一つあればいいサービスの共有。VPNやファイルサーバー
  • デフォルトVPCは共有できない
• 会社のAWS運用でも、事業部単位にオーガニを作成し、自由に使ってもらうことが出来る
• オーガニ間のデータ共有は、S3バケットでやることを推奨

RDBリファクタリングと異種間DB移行の戦い – Amazon DMSを使った止めずにリファクタリングする手法

データベースのリファクタリングのお話。 データベースの寿命はアプリケーションより長いため、データベースのリファクタリングは重要。 でも、アプリやバッチも必ず直さないといけないからコストがかかる。

• 非正規化はSelectのパフォーマンスは向上するが、Insert・Updateのパフォーマンスは下がる
• データベースリファクタリングという本があるが、日本語版は今は出版されてない・・・
• Aurora(MySQL)に書く　→　RDSのPostgresにデータをコピー（MySQLと同じの古いスキーマ） → データ作成時のトリガーで、新スキーマにリファクタリング

• AuroraとPostgresはAmazonDMSで接続

  • テーブル単位でデータを取得、ルールで加工することもできる
  • テーブル名やカラム名の違いを対応可能

• 更新頻度が高いとDMSが2〜3秒くらい遅延する

• 参照をAPIにして、リアルタイム性が必要なものはAuroraを参照する
  • 移行完了して新スキーマに切り替えても、APIなら影響を受けない
• DMSの問題点
  • DMSがローカルで用意できない
  • DMSが単一障害点
  • AuroraのURLが変わると止まる
  • トリガー失敗でDMSが止まる
  • DMSのタスク上限
• 元々DMSは一時的に利用するツール
  • 根底に据えるのは悪手
  • 予め使用する期間や目的を決めておく
• 手を動かしたものだけが世界を変える

金融APIでAWSを使う上での利点と欠点

カブドットコムのAWS刷新。 証券取引システムを構築したい企業のために、APIとインフラを提供する。 データはオンプレにあり、AWSでAPIを提供

• Cognite
  • 多要素認証、パスワードポリシーをGUIで
  • 他のマネージサービスと同じくらいと言われているが、耐久性の案内がない。
  • バックアップができない。CSVダウンロードできるが、リストアするとパスワードリセット。
  • エラーメッセージいけてない
• API Gateway
  • レート、バースト、クウォーターが便利
  • ただし、再作成時カスタムドメインの設定に時間がかかる（数時間）
• 認可はアカウント、ウォレット、注文で分けている
• APIの連携ではなく、顧客のVPCにプライベートリンクで接続する事例もある
  • Transit Gatewayを利用する

EC2からKubernetesへの移行をセキュリティ/モニタリングから考える

Freeeの事例 金融機関やクレカの情報だけでなく、法人向けサービスは生の経営情報を取り扱っていると同じで、セキュリティを非常に重要視している。

• サイバーキルチェーン
  • 攻撃者の攻略ルート、攻撃の段階を想定して対策する
  • AWSの責任共有モデルの考え方では、EC2に潜入されたらユーザーの対策
• VPCフローログでrejectのログを取る
  • 攻撃者は内部構造を知らないため、探索している可能性がある
• セキュリティグループでアウトバウンドをanyにしない（外に情報を出せなくする）
• AWS WAFだと、ペイロードが見れないため情報が不足。WafCharmを導入。
• DeepSecurityのログはシスログを利用
  • SQS連携は、トレンドマイクロのネットワーク通ってから通知するため20分ほどかかる
• Amazon GuardDutyはポートスキャンとか検知してくれるは数時間かかる
  • DNSクエリのログはとってくれないので自分で取らないとダメ
• EKSはDeepSecurityが使える
• k8s内の内部探索はSysdigで検知

AWS x JAMStack で構築・運用するサーバーレスなWeb Front

• JAMStackはJavaScript,API,MarkUpの頭文字
• サイトジェネレーターはGatsbyが人気。Reactベース
• アプリ系としては、Nextjs
• AWSではAPI Gateway,Appsync,DynamoDB,Lambdaとか
  • デプロイはCodeBuild
• https://dependabot.com/
  • Githubのpackage.jsonで使ってるライブラリにアップデートがある場合、自動的にissue立ててくれるサービス
  • Javaにも対応しているので後で試してみよう

見せてやろう…Serverlessの本当の力を…!!

• マイクロサービスは複雑化させない
• 依存関係の向きを揃える
  • 書き込みと読み込みで、同じデータを取り扱う必要はない
• 非同期処理をベースに設計する
  • 指示して待ってる（同期）なら、自分でやれ

• reInvent2018のセッション

  • https://www.slideshare.net/AmazonWebServices/building-massively-parallel-eventdriven-architectures-srv373r1-aws-reinvent-2018

• 非同期処理の利点

  • リクエストとレスポンスの依存を切り離せる。
  • 依存関係の向きが揃う
  • スループットをコントロールしやすい
• 課題
  • エラーハンドリング *リトライ可能なエラーはリトライ。
    • リトライできないエラーをどうするか
• API GatewayのWebSocketはただのマネージドなWebSocketではない
  • 非同期＋ポーリングの構築はツライ
• 接続に対してConnectionIDが振られる
  • ConnectionIDを使い、全く別のLambda関数からクライアントにデータが投げれる
  • 途中でエラーになった場合、エラーが発生した関数からClientに応答を返せる

Kubernetes on AWS/EKSベストプラクティス

ベストプラクティスは移り変わる。 このベストプラクティスは現時点（EKS Tokyoリージョンオープン）のもの。

• EKSはManagedなControlPlaneを提供する
  • GKEほど全部はやってくれない
• 小さく始めるなら、CloudWatch Logs、Elasticsearch
  • メトリクスはPrometheus
  • 分散トレーシングはX-Ray
• ツールはeksctl、terraform-aws-eksがおすすめ

• eksctlはプロダクションレディのクラスタも作れる

  • Cluster as a code

• ツール紹介は大量すぎるので元スライドで・・・

• EKSは造り込みを減らしたいときに採用すべき

  • ECSでもスケールはできる。数千サーバーの事例あり。でも、作り込みが多い。
  • 最新が使いたい、eksが信用できない場合はセルフマネージ
• cloudwatchはレートリミットと料金が厳しい。特にメトリクス。

運用のコツ

• 敷居の高さをカバー
  • 必ず相談窓口をおく。（代わりに運用をするチームではない）
  • 新規開発・移行・デプロイに関するドキュメントの整備
  • リファレンス実装を提供
• blast redius(爆発半径)はちいさく
  • 最悪、クラスタ全体が落ちる可能性がある
  • 1クラスタをマルチAZ、Pod間通信でAZを挟む
  • 神クラスタはダメ
• 標準機能でも使わないほうがいいものがある
  • persistence volumeはクラスタ作り変える時に問題になる
  • オートスケーラーはstaticで
  • サービスはNodePortで。LBにすると、クラスタ削除時にELBも一緒に消える
  • Ingressは使わない
  • external-dnsは、クラスタ作り直しが辛い
• クラスタのアップデートは失敗する可能性がある
  • k8sのクラスタをBGD
• ノード監視をサボらない
  • 時刻同期のずれとか見張る
  • kube-node-initで初期設定ができる
• k8sにロックインされないようにする
  • S3とかAWSのサービスはきちんと使う

まとめ

あの参加人数を、人数に対して広いとは言えない会場で運営していたスタッフさんに感謝。 内容は消化不良を起こすくらい満漢全席でした。