AWS Summit Tokyo 2019 参加レポ【後編】
こんにちは。 エンジニアの消火器です。
ちょうど一週間前の今日、 6月12日(水)〜14日(金)に幕張メッセで「AWS Summit Tokyo 2019」が開催されました。
今回はその参加レポート後編になります。 前編は@mikan3rdさんにより書かれたこちらの記事になります。
AWS経験について自分自身としては大きな運用経験は全くないのですが、 AWS様が運営するAWS loft TOKYOのAsk An Expert カウンターを利用させていただいて、 自社のやりたいことと現状、そこからどう理想に近づいていくかの話を丁寧にしていただいたのが記憶に新しいです。
今回はAWSの知見を得るために「AWS Summit行きたい…」とぼそっと社内で言ったところ、OKをいただき参加させていただいた次第です。
会場レポ
自分が参加したのは6月13日の2日目、 会場の幕張メッセまでは五反田のPatheeからだいたい一時間くらい移動し幕張メッセへ向かいました。
AWS Summitは幕張の1から3ホールを使用して行われました。
中もAWS Summitの誘導のカーペットが敷かれており、ゴージャス。
スポンサー様の看板、名だたる企業様が並んでしました。
外にはAWSに関連するワードの盛り上がり具合をモニタリングするモニターもありました。
会場に入ると、たくさんのブースが。
このブースでは出展企業様のAWS事例などが実際に聞くことができます。
自分もセッションの合間などで参加してきました。
AWSのセッションは、サイレントセッションという形式が取られていました。
サイレントセッションでは、各々にレシーバーが渡され各々のセッションに合わせたチャンネルに合わせ、イヤホンで聴くというのものでした。
そのため、4つのセッション会場に仕切りはなく、マイクから発せられる音もないセッションとは思えないほど静かなセッションでした。
イヤホンを使って各々のレシーバで音量調節をしたりするので発表者の声が聞こえないことはなく、仕切りもないのでちょっときになる隣の発表を聴くなんてこともでき、とても面白い形式だなぁと感じました。
セッションが全て終わると、re:MIXというナイトイベントが始まりました。
元々はJAWS-UGナイトと呼ばれていたイベントをベースに去年より構成を変更したものらしいです。
会場では軽食とドリンクが振る舞われ、いくつかの発表とウルトラクイズが企画されていました。
セッションレポ
自分が参加したセッションに関して簡易的ですがレポートの方を書かせていただきます。
AWSにおけるクラウドコンプライアンスの実践 ―セキュリティ担当者が理解すべき説明責任のポイント―
- 大きな話は3点
- AWSのセキュリティポリシーの悩みのヒント
- AWSがどのようなセキュリティを実現しているのという疑問のヒント
- グローバルスタンダードなセキュリティ対策へのヒント
- 話の核となるのはNISTのサイバーセキュリティフレームワーク、ホワイトペーパーの日本語版
- 自社のデータがAWSから侵害された場合、AWSが何をしてくれるか？
- NIST サイバーセキュリティフレームワーク
- サイバーセキュリティのベースラインとなるもの
- 「再構築より再利用」の思想
- あるものをうまく使い、足りないものをオリジナルで補う
- ITガバナンス
- ビジネス価値への貢献に対する説明責任
- 管理に対する説明責任
- ビジネス戦略との適合に対する説明責任
- 今やそういうセキュリティ的強さもビジネスの強さになってきた
- 組織の取るべき戦略は
- NISTの構成
- コア：カテゴリになる参考情報、職種・サービス別にマッピングされている
- ティア:昨日と統制の管理に関する成熟度を評価する指標
- プロファイル：自分たちの今の立ち位置と理想像
- AWSがどうやってサキュリティを実現しているか？
- 識別と防御と検知と復旧の4つで実現
マルチアカウント運用での権限委譲と統制の両立
- 組織内でのAWSアカウントの権限委譲と統制についてのおはなし
- 複数のAWSアカウントをどう運用するか？
- AWSアカウントとは
- セキュリティ上の境界線である
- リソースや制限の管理単位である(アカウントごとのソフトリミットあり)
- コスト管理の分離単位でもある
- 一般にアカウントは増える
- 最初は少数なのだが、経験を積むと自然と人&環境が増えていく
- なぜ増える？
- 多くのチームがあるから
- 環境鵜を分離したいから
- 分けることでコスト管理が容易だから
- アクセス権などを分離しセキュリティと統制を行いたいから
- マルチアカウント化する上で考えること
- 責任分担と権限委譲は適切か？
- 責任分担を明確化すること
- 適切な権限を付与すること
- 管理者と利用者が本当にやるべきことをやるために、アプリごとに利用権限を与える
- セキュリティと統制は適当か？
- AWSアカウントのアクセス管理
- やってはいけないことをしたときに通知をする仕組み
- ネットワークの中央管理
- 運用はどうか？
- 共有設定の展開と自動化
- 環境全体を俯瞰した監視
- 責任分担と権限委譲は適切か？
- 権限委譲のよくある例
- 環境全体の管理者：アカウントの作成者、管理。共通設定の展開
- セキュリティ担当者：セキュリティイベントの通知、ログを検査
- 利用者：開発者、リソースの作成など
- 実際どう運用するのか
SageMaker DeepDive
- 話の対象層は
- Sagemakerで機械学習プロダクション導入をしたい
- 成功のパターンを実現したい
- AWSにおける機械学習
- 開発の方針ユニークで、大部分はユーザのフィードバックを元にロードマップに作られている
- すでに作られたモデルを用いるサービスだったり、お客のデータからモデルを作成したりとニーズにあったものが作られる
- 開発の方針ユニークで、大部分はユーザのフィードバックを元にロードマップに作られている
- Sagemaker
- モデルの構築、トレーニング、デプロイを行うサービス
- いくつかのサンプルノートブックもある
- 学習は1クリックからでき、わずかなコード変更で様々な利用ができる
- ワークフローを助けるツール
- SageMaker Python SDK
- Dockerコンテナを用いた環境の統一化もできる
- 継続的なワークフローを作る
- トレーニングからデプロイまでの流れを自動化すること
- 継続的なモデルのアップデートを行うこと
- スケジュールに応じてキックしていく(これも自動化)
- とにかく自動化、できないところは半自動化
- human in the roopの考え
- AWS Step Function
- JSONベースでステートマシンを記述できるマネージドサービス
- LambdaやSagemakerが対応しています
- CloudWatchでスケジュール実行したり、イベント実行したり
- ワークフローの中で詰まる部分をしっかり改善する
- 課題によって詰まる部分は異なる、学習なのか、判別なのか
まとめ
自分はAWSをどう生かすべきかというところを思い今回のセッションを選択してみました。 AWSが提供しているサービスや仕組みと自分たちがやりたいことをしっかり練っていくことができれば、効率的にサービスを構築できそうだなぁと感じました。 特に、アカウント管理に関する部分は、実際こうするといいよと聞いても自分たちのケースをどう考えていくべきかうまくいかないことが発生しうると感じたので、 うまくコミュニケーションをとりながら適切でセキュアな管理をしたいと思いました。
また、機械学習に関する部分についても、 SageMakerを中心としたサービスをうまく使うことで、自分たちのプロダクトに機械学習を取り入れることも可能なのでは？、 というワクワクをとても感じるセッションを聞くことができました。
自分たちのプロダクトで今回の経験がきっちり活かせる日が来るように、 続報についてもしっかりアンテナを張っていきたいなと感じたAWS Summitでした。
