kglabo.blog

I will output what I thought.

「AWS Summit 2019」に参加してきました(2日目)#AWSSummit

どうもみなさん、おはこんばんにちわ!
ミナカワ(@yu_kgr)です。

2019/6/12 〜2019/6/14 に「AWS Summit 2019」というイベントがあり、AWSに対する理解を深めたかったので参加してきました。
当エントリはそのイベントの参加レポート(2日目)になります。

f:id:kgr0210:20190615022758p:plain

#8. AWS で実現する攻めのシステムモニタリング

  • 登壇者(敬称略) : 関山 宜孝(AWS Japan - 技術支援本部 クラウドサポートエンジニア)
  • 備考 : Collect(収集)-Monitor(監視)-Act(行動)-Analyze(分析) のサイクルで実現する “攻め” のシステム監視のポイントをお話しいただきました。

概要

攻めの監視設計のポイント

AWS Cloud上でどのようなシステム監視を始めればよいのか?

  • 攻めの監視とは、本来の要求を高水準で満たし、新たな価値を生み出す監視
なぜ監視をするのか?
  1. アプリの正常性をチェックするため
    • サービスレベル合意を定義して、達成度を測定する
    • 個別のリソースではなくアプリケーションレベルの状態を収集する必要がある
      • Webシステム 応答時間、HTTP 5XX Error率など
  2. アプリをもとの状態に回復するため
    • アプリが正常なのか、異常なのかを定義する
    • 異常状態への状態変化を検知する
      • メトリクスの閾値チェック
      • アプリからのメッセージ送信
    • 異常から正常に戻る方法を用意する
  3. トラブルの原因を調べるため
    • アプリ/リソースの動作状況を記録する
      • ログ・メトリクスを記録する
      • リアルタイム性が高いシステムの場合は高い粒度でのメトリクス・ログが必要
    • トラブルに関係する記録を保全する
      • 調査機関になりえる期間を定義する
      • リソース削除前にメトリクスやログを回収する
  4. ユーザー行動分析のため
    • ユーザー行動を記録する
      • アプリケーションレベルの行動ログ
    • 記録したユーザー行動を分析する
  5. キャパシティを分析するため
    • リソースに関する状況を記録する
    • 記録したリソース状況から将来のキャパシティを分析する
目的と監視方法がマッチしないアンチパターンもある
  1. 不適合な監視
    • これは監視する目的と監視方法が異なっているケース。
      • 例 : Webアプリの正常性チェックのため、Apacheプロセス監視
  2. 情報不足
    • 例 : オートスケールの結果インスタンスが消失してログも消失
    • 例 : リアルタイムシステムの調査用に 5分感覚のメトリクス収集
  3. 通知過多
    • 例 : 「Error」を含むログが出力されたら全部メール通知
      • 検知したい状態とアクションを常に対応するようにする

クラウドの特性を考慮した監視が必要。

  • CloudWatch = リソースやアプリケーションの監視
  • CloudTrail = APIの監視

適応型モニタリングのコンセプト

下記4つのステップからなるサイクルを繰り返して、監視設計をシステムに適用させ続けるプロセス

  1. 収集
  2. 監視
  3. 行動
  4. 分析
1. 収集

システム監視には、まず現状の把握が大切。
目的に合わせてメトリクスやログを収集して、現状を把握する。

  1. 監視目的から「収集対象/粒度/保存期間」を決める。
  2. 「収集対象/粒度/保存期間」はコストとのトレードオブ

メトリクスの収集は「CloudWatch Metrics」

  • 標準メトリクス
    • 各サービスにて提供されるメトリクス
    • CPU利用率 / ディスクI/O / レイテンシなど
  • カスタムメトリクス
    • アプリ特化 / API

ログは「CloudWatchLogs」「Kinesis Data Firehose」

  • Logを受信して、S3やElasticサーチに送ったりできる。
  • そのほか「CloudTrail」「VPCフローLog」「S3 / ELB Access Log」など
2. 監視

適切な方法で把握、監視する。目的に応じた監視。

  • 状態の可視化
  • アラート通知

通知頻度は、運用負荷とのトレードオブなので通知内容は厳選。
通知方法と宛先を検討すること

  • 重要なものは電話。業務時間の場合はメール…など。

ダッシュボードを作るには、

  • CloudWatch コンソール
  • Dashboards - 一般的にはCloudWatchDashboardがおすすめ。
  • Elastic Search Kibana - ElasticSearchに蓄積されたLogを検索・可視化
  • トラスティックアドバイザー など

通知の実現には、「CloudWatch Arams」からマトリクスが条件を満たした場合にSNSと連携して、リアルタイムにアラート通知を行う。Lambdaとくみあわせることもある。

3. 行動

収集・監視した状態をもとに、適切なアクションをとる

  • 状態に対して、適切なアクションをちゃんと定義する
  • リソースの調整、システムの回復を考慮する。

リソースの調整は、高可用性を活用。

  • 高可用性サービス / 高可用性オプションを持つサービスは自動復旧する
  • EC2 Auto Scaling
    • ELBと連携してヘルスチェックに失敗したら復旧できる
  • EC2 Auto Recovery

システムの回復は、Design for Failureの考え方を意識する。

  • システムの一部のコンポーネントが故障しても、アプリケーションは継続動作するように設計する
    • 「リトライ」と「べき等性」
    • 「ステートフル」より「ステートレス」

基本的にオートメーションで対処。

  • CloudWatchEvents
  • Lambda
    • サーバーレス環境で関数を実行できる
  • Systems Manager
    • SSM RunCommandで管理対象のサーバ上で任意Command実行
4. 分析

収集した状態を中長期的な分析する工程。
分析のための前準備として、データ加工しておくことが大事。

  • CloudWatch Logs insight
    • クエリ検索、集約
  • Elastic サービス
  • Athena

可視化するには?

  • CloudWatch Logs insight
  • ElasticSearch Service Kibana
    • こっちのほうがリッチ
    • こちらはアプリケーションの監視、Log分析にも使える

ビジネス・インテリジェンスで使いたい情報は?

  • QuickSight
    • 様々なDataに接続できるBI サービス
  • Amazon Forecast
    • メトリクスなどの時系列データを表示

監視設計は一度作って、そのままにしておくのは危険。 継続的に振り返って見直し、アプリケーションに「適応」した監視設計を目指すこと。

モニタリングデザインパターン

クラウドで構成されたアプリケーションの例と、ハイブリッドアプリの状態、ログ集約、分析プラットフォームパターンの三種類の説明があった。

MPD1: アプリレベル監視パターン

  • 外形監視
    • LambdaでHTTPEvent取得 => CloudWatchEvent(スケジュール)
  • 応答時間 / ELB
    • ELBアクセスログ => CloudWatchMetrics
  • リソース調整
    • オートスケール
  • 分析

    • Athenaでユーザ行動を分析
    • QuickSiteでユーザー行動を分析
  • ...etc

所感

既にある監視ツールの値を確認する事はありましたが、自分で監視設計をする経験はなかったので、このセッションを聞くことで、どのような考え方・設計で監視について考えればよいのか?という所の輪郭を掴む事ができました。

次回、そのあたりの設計に関わる機会があれば、デザインパターンと各種サービスの名前を思い出しながらやってみたいと思います。

#9. AWSで構築するデータレイク基盤概要とアーキテクチャ例のご紹介

  • 登壇者(敬称略) : 丹羽 勝久(AWS Japan - 技術統括本部 ソリューションアーキテクト)
  • 備考 : 「データレイクとは何か?」そして、データレイクを構築する場合にどのようなサービスで構築するのか、その周辺で連携するサービス、事例も含めてお話しいただきました。

概要

このセッションでお話頂いた内容は大きくわけて下記です。

  1. データレイクとは?
  2. AWSで構築するデータレイク基盤
  3. AWSのデータレイク事例
  4. AWS Lake Formation 概要

データレイクについて

近年、データは5年毎に10倍に成長しており、そのデータを15年以上保持することもある。

今回のキーワードである「データレイク」とは、システムからの生のデータのコピーと、レポート、可視化、分析、機械学習などから利用するため変換したデータを格納するシングルデータストア(非構造データ → 構造データ化して取り扱う)

それと対として挙げられる「データウェアハウス」は社内の書くアプリケーションやデータベースに保管された構造化データを収集して、上記同様に目的別に統合・格納して分析業務で利用するデータストア。

これら両方が必要となる理由はなぜなのか?

論理的推論で考える

ここまで出てきたビックデータを分析するにあたって「演繹法」と「帰納法」が登場する。

演繹法

演繹法では、トップダウン的なアプローチでデータを分析していく。
(大前提である条件から結論を導き出していく思考方法)

  1. 分析要件、目的を明確化
  2. データモデリング設計
  3. ETL設計
  4. 分析実行、レポート
  5. データウェアハウス / データマート

これにより「過去」から「現状の正確な把握」を行う。

帰納法

対して「帰納法」ではボトムアップ的なアプローチで分析する。
(多くの観察事項から類似点をまとめる事で結論を導き出す思考方法)

  1. 結果の可視化、レポート化
  2. データ変換、レポート化
  3. 分析の仮説化、理論化
  4. データの観察、パターン化
  5. 関連データ収集

これにより「未来の予測」を行う。

そのため、データウェアハウスとデータレイクの両軸での分析が必要となる。

AWSでは上記を相互に所有して、相互連携する事を推奨しているが、オンプレミスでのデータウェアハウス一択だけでは「高価」「低拡張性」「データ形式制限」「データ量制限」という問題と戦う必要が出てくる。

では、どのようにデータレイクを構築すればよいか?という所で本題。

AWSで構築するデータレイク基盤

データレイク
  1. Amazon S3
    • データレイクに最適なストレージ
  2. AWS Glue
    • データカタログ
      • データの構造・列や型、アクセス方法を定義しているもの
      • 表構造をHiveメタストア互換の形式で管理
        • 列・プロパティ・型
        • データロケーション(URI)
        • 更新情報など
        • クローラーによる自動チェックと登録を行う便利機能があり、Hiveパーティションを認識して登録を自動化している
    • ETL処理
      • 複数のデータStore間でデータ連携する際の取り出し(Extract)、変換(Transform)、ロード(Lord)処理
データウェアハウス

データウェアハウスは「Amazon Redshift」を利用する

また、拡張機能で、Spectrumというものがあるのでそれを活用する。 - S3上においたファイルを外部テーブルとして、直接参照し高速分析処理できる - Redshift内のテーブルと組み合わせて、高速にSQLでクエリ可能

AWSのデータレイク事例

AWSでデータレイクとデータウェアハウスを保持できるのはわかったけど「どのように連携すればよいのか?」という所に関してはこんな感じ
(解説されてた図を劣化コピー)

f:id:kgr0210:20190616170213p:plain

ビックデータの分析

連携した後、分析する時に使えるものは下記。

  • Amazon EMR
    • Apache Spark、Hadoop、HBase、Presto、Hive、その他のビッグデータフレームワークを簡単に実行してスケーリングできる
  • Amazon Athena
    • 即時にデータのクエリを実行。数秒で結果が取得できる
    • 料金は実行したクエリに対してのみかかる

AWS Lake Formationの概要

そして「AWS Lake Formation」というものがあるので、これを使うと データが配置される場所と、適用するデータアクセスおよびセキュリティポリシーを定義するだけでデータレイクを作成できます!という話でした。

所感

本セッションに関しては「そもそもデータレイクってなんやねん。ちょっと知るために見に行くか」ぐらいのレベルで参加したのですが「データレイクとはなんぞや」を知るどころか「ビックデータとの関わり方」から、それをどのように運用すれば良いかの概要を知ることができたのでなかなか収穫が多かったです。

#10. AWSにおけるデータベースの選択指針

  • 登壇者(敬称略) : 高橋 敏行(AWS Japan - 技術統括本部 ソリューションアーキテクト)
  • 備考 : AWSのマネージド・サービスの中で数々あるデータベース選択肢の中から最適なものを選ぶガイドラインを、ユースケースと交えて解説していただきました。

概要

データベースの歴史

2000年まではRDSがメインだったが「インターネット」が進化するにあってDBに求められる要件も進化。
この要件を満たすため、新たなDBが出てきた。

「万能のデータベースは存在しない」by AWS CTO Warner

という事で、用途に合わせてデータベースを利用しましょう。

用途に合わせた選択

データベースを選択する際には「要件」「やりたいこと」「ワークロード」に合わせて必要なデータベースを選択する(これをパーパスビルドと呼ぶらしい)

考え方としては、データカテゴリとユースケースに合わせて、専用のデータベースサービスを選択、利用すると良い。

(各DBの特徴についてはある程度知ってたので割愛!)

  • どのような情報をどういった用途で保存したいのか?
  • それに適したDBは、RDSなのかNoSQLなのか
  • データの永続化が必要なのか?インメモリで良いのか
  • その他、時系列、グラフ、台帳型などのDBもあるよ

所感

AWSのDBに関しては最近、社内の勉強会でも話を聞いていたので内容の復習…という感じでした。(特殊な用途のDBはよくわかっていないですが…)

  • 「データの特性を意識して、適切なデータベースを選択しよう!」
  • 「なんでもRDSに突っ込むんじゃねーぞ!」

という感じで、ちゃんと下記を確認すればよさそう。

#11. モダンなモニタリングへの変革!Datadog徹底解説

  • 登壇者(敬称略) :
    • 池山 邦彦(Datadog.inc- Sales Engineer)
    • 中川 誠一(Datadog.inc- Country Manager)
  • 備考 : Datadogを活用したモダンなモニタリング手法のセオリーをデモを交えてお話しいただきました。

概要

「Datadog」は何が良いのか?

AWSには「CloudWatch」があるが、なぜ「DataDog」を選ぶのか? - DataDogで 「メトリクス」「トレース」「ログ」と見える範囲が広くなる。

これまでの監視ツールだと「アプリ」はアプリ担当、運用は「運用面」の監視だけを行っていたが、Datadogではそこらへんの問題を解決して協業する事ができる。

AWSへの組み込みはAgentに対してIAMロールを付与するだけなので、各種ログをDatadogに集約する事も可能 - Integrationも豊富にあるので他のクラウドサービスとも連携できるという所が強み - 「タグ」の機能を利用する事で、状態ごとに分類して監視する事が可能。

サーバは「ペットではなく家畜として使おう」という考え方が大事。

  • オンプレだとサーバをペットのように面倒を見てきた
  • クラウドではサーバを家畜として、すぐに切捨、切替をできるように

ダッシュボードについて

DataDogに存在するダッシュボードは2種類存在する。

スクリーンボード

スクリーンボードはサービスレベルからパフォーマンスまで、全体を俯瞰する事ができる。

  • チーム間で共通の可視性を保つこと
  • 問題が発生しているところが特定できること
  • インフラ、APM、ログにまたがるタグ付けが重要
タイムボード

タイムボードは、サービスをドリルダウンしてリソースまで確認できる。

  • ワークメトリクス
  • アプリケーションのエラー
  • バックエンドDBのエラー
  • バックエンドDBのコネクション数やCPU利用率

独自の機能

  • 機械学習でクラスタパターン、ログを分析してお知らせしてくれる機能がある
    • 開発者は「エラーメッセージを見つける事」が目的ではなく、それを見つけて「どういった傾向、課題があるのか」を見つけるのが目的なので
  • 「API TEST」という外形監視もできる
  • UI上からポチポチするだけで「E2E」テストを行える機能も4月に実装した

所感

Datadogに関しては、社内の説明会で「出来る事・活用方法」を実際に聞いた上で、ダッシュボードをちょくちょく見ていたのであまり目新しい発見はありませんでしたが、 改めての復習…という感じになりました。

#12. AWSトレーニングプログラムの紹介とクラウド学習のコツ

  • 登壇者(敬称略) : AWS Japanのソリューションアーキテクトの方(どなたかわかりませんでした XD )
  • 備考 : Expo会場内であったミニセッションでAWSを学んで行きたいエンジニアは、どのように学習していけばよいか?というものがあったので参加してきました。

概要

前置き

元より覚える事が多いエンジニアですが「なぜ学び続ける必要があるのか?」という前置きから話が開始されました。

  • 「今後、IT需要に対して人出がまったく足りなくなるよ!」って経済産業省が調査結果を出している
  • 「スキルセットやビジネスモデルをクラウドベースのものに転換してく必要があるよ!人間がやらなくていいことはやらないようにしてけ!」って経済産業省が言ってる

こんな状態で、

ただ学ぶにしてもクラウドサービスについて学ぶ事がそのまま効率化につながるし、AWS自身もすごい勢いで成長してるから学んだ技術自体もそのまま強くなるしで一石二鳥になる!

どのように学ぶか

要望に対して人手も足りてないし、めっちゃ学ぶ必要があるのはわかったがまず概要からどう学んでいけばよいのか?

そんな質問に対して、AWSでは各所から情報を無料公開している(効率的な習得したい方は有償もある)

デジタルトレーニング

AWSを知る方法(非開発者向け)

AWSを知る方法(開発者向け)

有料クラストレーニング

AWS認定のインストラクターから学ぶ事が可能。
無償トレーニングとの違いとしては、実務ベースでのケーススタディをより知る事ができ、現場でのベストプラクティスを学ぶ事ができて、より効率的との事。

サービスについて知る

Self Learningのコツ

「なるほど、どういうものがあるのかはわかったから、どう学んでいけばよいのか?」

そんな質問に対して、
AWSの方が新サービスをどのように自分の中に取り込んで学んでいるのかを共有してくれました。

アンチパターン

学ぶ時によくあるアンチパターンとして、こんな事があるある。

  1. カンファレンスで聞いた内容に感銘を受けたので週明けのMTGで報告しようとしたが、内容がよく思い出せない!
  2. 勉強会でAWSのサービスについて聞いてきたので自社に戻ったあとで報告した所、デモンストレーションを求められたが、どうすればよいのかわからない!

これらのように、目的を決めずに「インプット」してしまう形は効率が悪い。

アウトプットの戦略

ではどうするのかというと、先に「アウトプットする目標」を決めた後で「インプットするターゲット」を決める。

情報のインプットを行う「アウトプット駆動」がベスト。
このアウトプットが起点となるサイクルが学びにつながっていく。

  1. アウトプットする
  2. フィードバックをもらう
  3. またインプットする

ではどのような「アウトプット」を選択すれば良いのか?

  • 実際にビジネスに貢献する(業務利用する)
  • プログなどで情報発信する
  • 社内勉強会で共有する
  • ITコミュニティで登壇する

基本的に実際に利用したり、人に伝える内容が良質なアウトプットと言える。
これは「ラーニングピラミッド」でも同様の事が言われている。

ひとりだけでは続けにくい…という方は社内勉強会などで人を巻き込んでやっていくと吉。

インプットの戦略

そうは言ってもAWSからの情報はとても多いがどうしてるのか?というトピック。

基本的には「自分が欲しい(知りたい)情報」にスコープをあわせて取得していく。

コツ その1 - 毎日、小さくインプットしていく

  • What's New
    • サービスのすべてのリリース情報を掲載している
  • AWS ブログ
    • 新サービスや最新情報をく欲しく解説している
  • 週間 AWS
    • 最新情報を一週間単位でコンパクトに紹介している。 毎週火・水目安で更新されている。
  • AWS Service update
    • 毎日のようにアップデートされる新機能や新サービスを動画で紹介。

AWSの方は、これらの情報をRSSやFollowして自動取得して通勤時などに確認する事を習慣化しているとの事。

コツ その2 - まとめてぎっしりインプットする

一気に取り込んでいきたい場合は、カンファレンスやセミナーを有効活用すると良いとの事。
基本的にAWSのカンファレンスは「学習型」なので「事例」「まとまった情報」「技術的に高度な情報」を多数発表している。

  • re:Invent
    • 400本近いブレイクアウトセッションのほぼすべての資料・動画がSlideshareとYouTubeに公開している
  • AWS Summit Tokyo / Osaka
    • ほぼすべての資料と動画がWebサイトに公開
  • AWS Innovate Online Conference
    • 日本初の大規模なAWSオンラインカンファレンス

その他、各種コンテンツを確認すると学びを深める事ができる。

  • AWS クラウドサービス活用資料集
    • 様々な切り口(業種 / サービスカット)での資料・動画が確認可能
  • AWS Answers
    • AWS ソリューションアーキテクトが開発したドキュメントやソリューションのリポジトリ
    • 規範的なアーキテクチャのガイダンスが提供されると同時にAWSアカウントに数分でデプロイ可能な自動化されたソリューションも用意している
  • AWS ユースケース
    • AWSの基礎情報をハンズオンで学ぶ事ができる。
    • 10分チュートリアル、無料枠で出来るものを多く揃っている
  • AWS Samples
    • 多数のハンズオンへのリンクがあり、AWSユースケースよりも発展的なハンズオンでインプットを強化したい方にピッタリ。
  • よくある質問
  • ナレッジセンター
    • 多くの利用者の疑問、質問を知る事が可能。
    • 自分の体験していない事例について、知見を広める事が可能。
    • ちなみに、よくある質問に比べてナレッジセンターはあまり知られてないのでぜひ見てください!との事
フィードバックサイクル

これらを通して言える事は 「情報は、発信する人に集まる」 との事でした。

所感

学習方法に関しては「アウトプット大全」で触れられていた内容も出ていたので、わかりみが深い内容でしたが「インプット → アウトプット → フィードバック」の流れではなく「アウトプット → フィードバック → インプット」の形で、先にアウトプット自体を軸にしてしまうと言っていたのが、とても印象深い内容でした。

なんとなく参加したセッションが激アツでした。どんどんアウトプットしていこう。

#13. Architecting for the Cloud 2019 クラウドにおけるアーキテクチャの設計原則

  • 登壇者(敬称略) : 荒木 靖宏(AWS Japan - 技術統括本部 ソリューションアーキテクト)
  • 備考 : AWS のメリットを活かした、クラウドらしいアーキテクチャを構築するための原則についてお話しいただきました。

概要

話の内容としては「クラウドにおけるアーキテクチャの設計原則を見直しましょう」という内容で、そのため考える必要があるのは下記。

  1. 障害を見越した設計
  2. 全レイヤでのセキュリティ実装
  3. ストレージの選択肢活用
  4. 伸縮性の実現
  5. 並列で考える

障害を見越した設計

  • 「AMI」や「ELB」を使う事で障害前提の構成を考えること。

ストレージの選択肢活用

ストレージに関してはS3以外にも色々あるので最適なものを利用してほしい。

  • Elastic File System
  • Elastic Block Store
  • Amazon Glacier
  • Amazon Aurora
  • Amazon DynamoDB
  • Amazon Elastic Cache

伸縮性の実現

  • 「ブートストラッピング」or「Golden Image」
  • 家畜として扱う(ペットではない)
    • Datadogのセッションでも取り上げられていた話題
  • サービス継続性の重視

並列で考える

  • 「サーバ1台で100時間」より「サーバ100台で1時間」
  • なめらかなスケーリング
  • 障害影響範囲を小さく
  • ソフトウェアの書き換え

疎結合はあなたを楽にする

  • よいインターフェース定義
  • サービスディスカバリ
  • 対応できないときの非同期処理
  • 失敗時の適切な処理

制約を恐れない

  • 制限には理由がある
  • 提供できるものを計画する
  • うまくいくものを出荷する
  • 出来るときに出荷する
  • 繰り返し繰り返す

まずは「シップイット」

出来る時に出荷しましょう。慌てて出荷するのは無理です。 
「出来る時に出荷しましょう」

この考えがとても大事。

実践編(Webアプリ編)

これらを実践するにはどうしたらよいか?

  • セキュリティは常に最優先
    • ほとんどのWebサービスは外部に開かれたサービスのため
  • 必須 : アカウン要不要 / 権限管理、認跡

Productionアカウントに関しては少なくとも次の3つを実施すること。

  • IAMユーザ / グループの設定
  • CloudTrail, Config, GuardDuty, Security Hub, MFAの有効化
  • Enabling and Disabling Regions
    • 自分が使うリージョンはどこなのかを意識して、使わないリージョンを無効化する

今後、aws-landing-zoneという機能をリリースするので、上記の3点は手動で対応しなくてもよくなる予定ですが、現時点では手動で上記を設定してほしいとの事。

https://www.google.co.jp/search?q=aws-landing-zone

ちなみに、下記を利用すると設計原則をいちいち意識しなくても良くなるので、 下記を利用する事を合言葉にしてほしい。

  • AWS Well-Architected Tool
  • Trusted Advisor

所感

AWS Well Architected」に関しては、概要と名前だけは知っていましたが、本セッションではその内容により突っ込んだ内容となっており、より有意義な情報だったので見返して活用したいと思います。

2日目の感想

f:id:kgr0210:20190616235547j:plainf:id:kgr0210:20190616235610j:plain

2日目は1日目の反省を兼ねて、各企業ブースも見るようにしました。

  • 「mackerel」「Datadog」「NewRelic」の監視サービス各社に違いを聞く
  • 認証系SaaSの「Auth0」のブースで説明を聞く
  • スタートアップ各社がどんなプロダクトを開発しているのか見る
  • 加藤さん(@PharaohKJ)に拉致られてJAWS-UGブースに連れて行かれる
  • 弊社から登壇される安倍さんとバッタリ会って会話... など
    • 安倍さんセッションはクラメソさんがレポート化してしました :-D
    • 尚、上記レポート内の「社内AWSの勉強会」には私も参加しましたが最高でした

3日目はコンテナやサーバレスのセッションを中心に参加してきたので、またそちらのレポートを記載したいと思います。

他の日程のレポート

1日目のレポートはこちら

blog.kglabo.com

2日目のレポートはこちら

blog.kglabo.com

3日目のレポートはこちら

blog.kglabo.com