JAWS DAYS 2018 行ってきました!レポート

JAWS DAYS 2018行ってきました!
jawsdays2018.jaws-ug.jp

実は今回が初参加なので、
他のイベントと比べてどうなのか、わくわくして参加しましたよ!
レポート、書き殴っていきますっ!!

レポート

【ALL】10:10~11:00:A story of cloud journey with Community

  • 内容としては主に登壇者の方が経験したコミュニティ変遷。
  • 100回の参加より1回の登壇〜。
  • 明後日の方向から飛んでくる変化。

【A】11:10~12:00:Enterprise Serverlessを実現するための信頼性エンジニアリング

speakerdeck.com

  • Serverlessってなんだっけ?
    • CNCF Serverless Whitepaper
      • サーバの管理を必要としない。サーバーオペレーションがなくなる。
  • サーバーレスの信頼性は、FaaSに依存してしまうので、ビジネスの継続性を担保できない可能性。Reliabilityを保証できない?
  1. Faas・・・コンテナ内で非同期に呼び出される関数
  2. Baas・・・フルマネージドかつ抽象化されたライブラリやMW
  • Serverless is...抽象化されている関数やMW
  • 信頼性の考え方
    • ネジネスの信頼性を保つ努力をするのは変わらない。
    • Think simple, Keep simple(いいね)
  • 設計
    • イベントは同じ方向に流す。(逆流させない。)
    • 結果が必要なら同期で返す
    • 取りに行かせる
    • 一連の処理には同じIDを付与
      • それを引き回すことでIDでトレースできる
      • IDは様々な制御に使える
    • DynamoDB 結果整合性
      • 非正規化テーブルの、dynamodbはトランザクションの整合性
        • 保てる方法:条件付き書き込み、asid trunsaction
    • RDBとlambdaの相性の悪さについて
      • VPC lambdaで起動すると遅い。遅延発生厳しい。
      • 書き込みは非同期にすれば問題ない。
    • Functionのテストはユニットテストでちゃんとやろう
  • 監視
    • serverlessでやるべき監視はapplicationからのエラー通知を作り込むこと
      • ちゃんとエラーはキャッチして通知すること
      • メトリクスはちゃんと見ましょう。メトリクスを集約できるのかもIaaSの選定のポイント。
  • まとめ
    • サーバレスは特別なことではない。
    • 信頼性が必要な部分はちゃんと作り込む
質問内容メモ
  • サーバーレスでもたちあげっぱなしだとEC2より高くなる・・
    • コストを下げるコツとして・・間にAPIゲートウェイを挟んでキャッシュできるデータをキャッシュすれば、lambdaが実行されないのでやすくなる
  • CI環境はコードビルドを使って、AmazonLinuxのイメージを作ってそこでテストする。
    • Githubからソースを取得して、Pythonの関数をテストする。
    • 登壇者の現在の仕事はbackendが複雑なパターンが多い。frontが重要なサービスならfrontからのテストをちゃんとやったほうがいいよね的な。
  • 監視の方法は?
    • 死活監視は外側から叩く方法と、Cloudwatchのデータをdatadogにつっこんでる。datadogはserverlessだとお金取られないので便利。(なにー!そうなのか!)
    • TraceIDのチェックで10分以上途切れていたらメトリクスに上げるとか。

【ALL】13:00~13:50:「AWS Technical Evangelists Special talk session -スペシャトークセッション AWSとユーザーコミュニティが生み出すNo borderな未来-」

  • 認定エンジニアになるための勉強方法
    • associateの試験は結構簡単。少なくとも2回目はパスできる。
    • ネットワーキングのプロフェッショナルスキルは大変。85%しか正解率はない。
    • API, SDKだけでなく、Architectureを見る必要がある。どうやってAWSを使っているのか事例を見ることが大事。
    • 認定とプロジェクトでは違う。認定で学んだことは使わないことがある。プロジェクトは主流を学ぶ。
    • 認定は重箱の隅をつつくような内容が出てくる。模擬試験などをこなして進めるしかない。
    • ハンズオンを利用することが最も重要。たくさんの試験があるけど、単語や用語などの明確な理解が必要。
    • 認定に関して:8つの認定のうち、2つの認定は日本語化されていない。
  • 一番最初に学ぶべきのプログラミング言語は?
    • 同僚の方を見てどの言語に投資しているのかを見て学ぶべき
    • プログラミング言語はただのツールなので、言語を選ぶのは重要ではなくて、問題を解決することにフォーカスを置くべき。
    • 右手でビルド言語、左でスクリプト言語というまぁ、両刀使いになるとか。
  • 今何が起きているのかを正しく理解すること。
    • 日本はまだEC2の利用が圧倒的に多い。だんだんサーバーレスを進めていくというカルチャーに違いはない。
    • テクノロジーを使う準備ができているのか、人の成熟度などが国によって違ってくる。
  • コミュニティの特徴について
    • 韓国のコミュニティはクレイジーだった。すごく飲むので。
  • 今後のトレンドについて
    • ハンズオンによる経験が何よりも重要。codeを書くことから卒業していく段階になっても、それでもハンズオンを続けて学び、アウトプットを出す。それによりトレンドを予測できる。
    • リージョンの境を越えたグローバルなアーキテクチャ構築
    • 仮想通貨やブロックチェーン
    • ユーザーインターフェースは今後もあまり変わらないと思う。
  • ラーンアンドビーキュリアス
    • 学んで明日やる。今後やるとでは雲泥の差がある。
    • learn and be curious

【G】14:00~14:50:ユーザー企業におけるサーバレスシステムへの移行

speakerdeck.com

  • なぜ、サーバーレスに至ったのか
    • 大規模システムは嫌です。システム変更による影響範囲が広くて、テストが大きくなる。
    • 密結合はいやです。固有のインターフェースに基づいて接続。一方が他方を容易に取り替えられない。
    • インフラ管理は嫌です。プログラムに注力できるつまり、ビジネスに注力できる。
    • 処理の考え方としてスケールアップは嫌。159億データさばくなら、必然的にスケールアウト
  • システムを小さく、疎結合で、インフラを持たず、スケールアウト型で開発しよう。
  • サーバーレス使って見た
    • S3
      • ファイル移動が失敗する時がある。All moveでなぜか残っている。ポーリング
      • ファイル名を意識する。日付とかつけちゃうとアクセス効率が悪い(公式アナウンスはない)。
      • ハッシュ値 + ファイル名をつけることでパーティションかを回避的な。
        • 1秒間に800リクエストある以上の場合に採用した。
    • SQS
      • Queuing chain クラウドデザインパターン
      • 実行保証、複数回うごくことがある。この時の工夫方法。冪統制。
      • スケーラベル、順番保証されない。-> 結果整合性で設計する。FIFOオプションという選択肢もある。
      • Pub Subによる拡張を見越した設計。Fanoutパターン。SNSとSQS
    • Lambda
      • イベント駆動でスケーラブルで無駄がない。EC2の場合時間帯によって無駄があるとパターンが出てくるよね的な。お金に直結する的な。
      • 最大5分問題 -> 前処理を切り出すとか、処理時間を掴むとか。
      • ソース容量足りません問題。解決策なし。
    • DynamoDB
      • 結果整合性(並列と相性が良い)
      • 書き込みキャパ問題(お金はかけたくない)-> lambda同時起動数を制御しキャパシティ超えをおこさせない。
  • 開発手法
    • コーディング:Cloud9を採用。atom+sam、eclipse+samも検討したがマシンスペックに左右されるのでクラウドを利用した。
    • ソース管理:GitHub 細かいプルリクで差分を確認し、ナレッジ共有。いいよね。
    • CI/CD:circle ci使ってる。cloud formationの欠点?:Lambdaの同時実行数が設定できなかった。-> AWS CLIの実行で解決。
  • 感想
    • 苦労しましたか?
      • インフラはらくちんになった。0ではないが。
      • アプリは苦労した。新しいことをやることは当然、苦労するのでそうだよね。今は0.8。awsは制約があるから、迷わないからいい。優秀な先生がたくさんいる。
    • 作られたシステムの出来は?
      • インフラいいことだらけ。AWSが結構サーバ落ちたりする。落ちる前提のデザインで作らないとダメですってこと。
      • アプリもいいことだらけ。クラウドのメリットを簡単に、大きく享受。

【A】15:00~15:50:コンテナを守る技術 2018

speakerdeck.com

  • DockerHub 2015年の状況
    • コンテナは、Officialだから安全というわけでもない。
  • コンテナを運用する不安
    • アプリケーションの詳細な挙動、把握できてる?
    • AWSでのセキュアな構成、設計できていますか?
    • セキュリティポリシーをテストする仕組み、ありますか?
  • これまではホストごとの管理が基本
    • これからは、SGはAllow nothing, コンテナ毎に必要なroleを付与
  • アプリの挙動を把握しよう
    • どれくらいのリソースが必要?
    • どこと通信する?
    • ファイル書き込みはする?どのディレクトリ以下?
    • 内部的にセキュアな構成になっているか?
  • ホストまで管理する?
    • いろいろと規定がある場合に、管理するかも。
    • ECSがいい。ホスト管理したいなら。
    • メリットとしてアプリケーション毎にSGを振ることが可能。
  • ホストは忘れたい場合
    • fargateがいい。
  • ECSタスク定義
    • dockerが本来持つセキュリティオプションも数多く使える
  • セキュリティのチェック
    • 都度テスト:継続的にポリシー上問題がないことを確認する
    • 定期テスト
    • 実行時スキャン

(コンテナ内の脆弱性を考えるって本当に大事だよね。
パッチ当てなどの作業もコンテナ単位でやることになるのかしら。)

  • ホストとコンテナ
    • 守りやすい環境を整える
  • ホスト
    • これまで通りに守る
    • インスタンスハードニング、堅牢化
    • セキュリティ製品のインストール
      • aws inspector試してみて
  • docker-bench-security
    • コンテナを本番で動かす場合、best practiceをスクリプトで確認するためのツールになる
    • Lambdaで自動化をすれば、コストがとても安い
  • ECSエージェント
    • 特権を持つコンテナの起動を許可しない
    • コンテナ起動時にdocker security optionを使いたいケース
  • リソースの分離について
    • きちんとリソース制約 - 巻き込み事故を防ぐために
    • unlimitsで利用できる上限を決める
    • memoryを指定して、それを超えたらコンテナを落とす など
  • READ ONLY
    • 書き込めなく手段を利用する。AppArmorとか
  • ルートユーザは使わない
    • システムコールに正しく権限チェックがかかるように
    • 面倒がらずちゃんと適切なユーザを作りましょう
    • アプリケーションにあった方法で
  • 実行ファイルの管理
    • 利用するバイナリだけイメージに入れる
    • できれば静的リンクにしておく
  • ビルド
    • CI
      • static application security testingツールの利用
      • Dockerイメージのポリシーを定義&チェック
      • GoogleCloudPlatform/container-structure-test
  • 新たな脅威への対応
    • イメージの静的解析
    • SaaS:aqua, NeuVecor,
  • SSM Parameter Store & KMS & IAM Role
  • チームで意識するセキュリティ

【H】16:00~16:50:[DeepDive] AWS Japan SA Lightnings!

  • Lambda@Edgeでできること
  • aws guard duty
  • remak.js
  • cfn-flip
  • cross stack reference
  • Systems Manager Parameter Store
  • StackSetsで複数アカウント&リージェンへ一括展開

所感

初めてのJAWS DAYS!コミュニティの温度感の違いを感じました。

コミュニティは所属している人達によって文化やノリが変わるものだと感じました。
特に今回はテーマが「no border」ということで国際的な交流と、それに伴う親切心を感じ取れました。
全てのJAWS支部が同じ温度を保っているわけではないと思いますが、
今まで参加したコミュニティとは違う雰囲気を感じました。素晴らしいことです。

AWSはカテゴリが多岐に渡るので、ひたすらに技術要素をキャッチアップできる

今回の登壇資料を全て見ることだってまだ追いつかないくらい。
そしてそのカテゴリも多岐に渡る。AWSは進化が止まらないので、飽きることもなく本当に楽しいと思います。

各セッションは部屋ではない。間仕切りがある程度。

これは今までの勉強会と比較してのことですが、間仕切り程度でセッションエリアが区切られていました。
これについては特に問題ないのですが、当然のごとく周りの音で登壇者の声が聞き取りづらい場合があるので、
レシーバーの利用は必須ですね♪

以上です!
参加した皆様方、スタッフの皆様方、お疲れ様でした!