お疲れ様です。クーコムの大越です。
6/12~14の3日間はAWSを利用している方ならだれでも知っているであろう「AWS Summit Tokyo 2019」が開催されました。
僕は今回、2日目である6/13に1日参加させていただいたので、そのレポートをここに書かせていただきたいと思います。
そのまえに。。。
ちょっとレポートを書く前に、ここで皆様に報告しなければならないことがあります。。。
当日の朝、「AWS Summitでいろいろモチベーション上げに行くぞ~!」と気揚々と駅を降りて会場に向かっていた僕ですが、なにか周り様子おかしいこと気が付いたんです。。。
改札から降りる人たちがみんなスーツばっかりで、エンジニアっぽくない。しかも持っている受付表の色が明らかにおかしい。。。
それでも「いいや、きっと隣の会場で違うイベントやっているんだ。何も変なことはないじゃないか。こんなところでイベントするなんでやっぱAWS様だわ~」と心に言い聞かせ会場へ歩いていきました。
ただ1歩歩くごとに不自然な点が次々とでてきたんです。。。
– AWSのTシャツを着て道案内している人が1人もいないこと。。。
– AWS Summit特有の紫色の広告が全くないこと
– “東京おもちゃショー”という文字はたくさんあるのに”AWS”という文字が1つもないこと
そして会場について開催中イベント一覧を見たとき自分の中にあった疑念がついに確信になりました。
そう、僕は「幕張メッセ(国際展示場)」ではなく、「東京ビッグサイト(東京国際展示場)」に来ていたのです!(デデーン

ひとまず報告するもあまりの意味が分からなさに困惑している上司の図
今回のAWS Summitで一番学んだことは
「どんなに慣れていることでも事前チェックや予習はしっかり行おうね!!」という点でした。。。
本編
はい、しょーもないことで文字数を稼いで申し訳ないです。
それでは今回のレポートを書かせていただきたいと思います~
全体の様子

入口
今回僕は、2日目の6/13(木)に1日参加させていただきました!
今年は幕張メッセで行われたためか、去年と比べてExpoのスペースが増え回りやすくなったことや、前回みたいに異なる階層にあるわけではないので各セッション会場への行き来もしやすくなったように感じられました。
また、AWS DeepRacerの特別ブースが大きくとられていたことも1つの特徴だったと思います!
※AWS DeepRacerについてはクラスメソッド様のこちらの記事が詳しく書かれているのでどうぞ!
https://dev.classmethod.jp/cloud/awssummit2019-deepracer-league/
聞いたセッション
今回聞いたセッションは以下の通りになります!
- A2-2 IoTデザインパターン
- B2-03 Amazon WorkSpacesの運用管理
- J2-04 モダンなモニタリングへの変革!Datadog徹底解説
- F2-06 CI/CDが確変する開発現場・ビジネスとCircleCIの未来
- I2-09 AWSで実現する攻めのシステムモニタリング
- A2-10 re:Mix
ものすごく分かりやすい上に詳細な記事はすでにクラスメソッド様の記事が書いていただいているので
個人的に気になったセッションをここではご紹介したいと思います。
※クラスメソッド様のリンク張っておきます。
https://dev.classmethod.jp/series/aws-summit-tokyo-2019/
J2-04 モダンなモニタリングへの変革!Datadog徹底解説
概要
マイクロサービス化やアジャイル開発、DevOpsにより、開発サイクルは短くなり、またリリース頻度は高くなっています。新サービスを安定して提供することがミッションとなる中、目標に向かうために必要なことは何でしょうか? サービスレベル目標の達成状況や定常的なUXの可視化はもちろん、問題やインシデントをいち早く検知し解決すること、また、全員で共通認識を持つことが重要となります。 このセッションでは、このような課題に直面したときに必要とされるモダンなモニタリング手法のセオリーをデモを交えてお話しします。
スピーカー
- Datadog, Inc. Sales Engineer
- 池山 邦彦 様
- Datadog, Inc. Country Manager
- 中川 誠一 様
内容
- 弊社クーコムでも最近導入し始めたDatadogです。
- Datadogを使うことによって「スピード」「クオリティー」「コスト」の3つを最適化することができる
- Datadogの主なサービスは以下の3つ
- メトリクス
- トレース
- ログ
- これら情報を関係者全員が見て、同じ価値観で問題に対して取り組めるプラットフォームである、とのこと。
-
また、Datadogのサービスで初めて作るときにとても悩んでしまう「スクリーンボード」と「タイムボード」の指南として、各チーム間で共通の可視性を維持し別チームのボードを見ても直感的にわかるようにしておくのが良いという指南も。
-
そしてインフラやAPM、ログにまたがるタグをつけ、問題発生時にタグで情報を探索できるようにしておくことも大事。
-
最近サービスの提供が始まった、E2Eテストにも実は機械学習が組み込まれててデザイン変更に柔軟に対応してくれるらしい。
-
アラートについてはSLOウィジットでサービスレベル目標を可視化しておき、何をもって問題ないと判断できるかをあらかじめ決めておきそれに沿って設定すると明確になる
F2-06 CI/CDが確変する開発現場・ビジネスとCircleCIの未来
概要
CircleCIは世界最大のCI(継続的インテグレーション)/ CD(継続的デリバリー)のクラウドプラットフォームで、コードがビジネスアイデアから製品としてリリースされていく際の中心的なハブとなります。このセッションでは、CircleCI CEOのジム・ローズが、CircleCIのロードマップやなぜ日本が開発のイノベーション拠点として注目されているのかについて逐次通訳で説明します。それに続き、CircleCI カントリーマネージャー 森本とジャパンテクニカルリード 金から最新のアップデートなどについてお話します。
スピーカー
- CircleCI合同会社 CEO
- Jim Rose 様
- CircleCI合同会社 カントリーマネージャー
- 森本 健介 様
- CircleCI合同会社 ジャパンテックリード
- 金 洋国 様
内容
- CDとは具体的にどんなメリットがあるのか?というお話がメイン
- CIでは環境の違いによる問題があったとしても気づくことができない
- それはテスト可動範囲は意外と小さくビジネス要件、仕様、外部サービス、トラフィックなどはテストできない
- なので結局は「結局リリースしてみないとわからない!!!」という重大な気付きをえた
- ただし気を付けるべき点は以下の通り
- 修正をすぐリリースできること
- この時にヒューマンエラーがないように注意する
- 切り戻しが容易であること
- 自動することによって時間がかからないようにする
- これら要件を満たすためにCDが必要になってくる
-
リリースエンジニアリングの分野での以下2つの意味
- 「デプロイ」
- 本番環境にコードを置くだけ
- 「リリース」
- 配置したコードでトラフィックを処理すること
- ブルーグリーンデプロイメント
- 「ブルー」と「グリーン」の2つの環境を用意して、デプロイする際に2つの環境の役割を切り替える手法
- カナリーデプロイメント
-
本番環境の一部分にデプロイし、先に一部のユーザに提供後、問題がなければ全てのデプロイを行うという方法
-
CDとリリースエンジニアリングを活用することで本番環境で効率的なテストができる
-
そしてフィードバックループができるようになる
-
OrbsでCI/CDを今までの設定を再利用できる
-
CircleCIが従量課金モデルが出た!
- 分ごと課金らしいので料金を抑えたい方は料金の見直すをすることをお勧め!!
A2-10 re:Mix
その他
EXPOのほうも全体的に回らせていただき、
AWSStepFunctionやDocumentDBついてお勉強させていただきました。
趣味のIoTでもAWS認定試験でもServerless関連の技術はよくでてくるので今後はこの方面を極めて行こうと思います。
それでは私からは以上です。
また記事を読んでいただけたらと思います。
それでは!