はじめに
- この記事は、Qiitaアカウントの整理のため、別のアカウントで投稿した過去の記事を移行してきたものです。全く同様の記事があるかもしれませんが、盗作等ではありませんのであしからずご容赦ください。
- 過去記事 投稿日:2019年06月14日
概要
1日目は参加できず、2日目より参加
思ったより参加者が多く、AWSの盛り上がりを実感。
各ブースまわってみたりしたが、聞きたいこととかちゃんと整理しておかないともったいないなと痛感。。。
あれだけの人数がくるんだから、なかなか担当者捕まらない。担当者捕まえたら聞くことちゃんと聞けないともったいない・・・
結局グッズ集めに終始・・・
DeepRacerはやってみたかったけど、120分待ち!!あきらめた。。。
ちょっと眺めたけど、やっぱり面白いな、なんだろうな、あれ。
機械学習めっちゃ興味ある。
明日最終日も一日参加できればいいな。DeepRacerセッションと、DynamoDB DeepDiveが楽しみかな。
以下、参加したセミナーのメモ
WindowsシステムをAWSで動かす勘所
-
Windows On AWSのメリット
- Windows ワークロードのスケールが可能
- リージョンとAZ
- SQLServerのAlwaysOnをAZ間で
- リージョンとAZ
- 俊敏性の向上
- 例)SQLServer
- フルマネージドーRDS For SQLServer
- 自動フェールオーバー、S3へのバックアップ含めてマネージドサービス範囲
- 容易なバージョンアップ
- 自己構築ーSQLServer on Amazon EC2
- フルマネージドーRDS For SQLServer
- Amazon FSx for Windows File Server
- フルマネージドのWindowsファイルサーバー
- Pure Windows Windows ファイルシステムと完全互換
- コンプライアンス準拠
- フルマネージドのWindowsファイルサーバー
- 例)SQLServer
- コスト最適化
- インスタンスファミリーとストレージタイプを自由に組み合わせ可能
- ライセンス調達の柔軟性:BYOLも可能
- AWS License Manager
- BYOLライセンスの管理とコンプライアンスの徹底
- ライセンス範囲外の利用を制限する等の管理が可能
- BYOLライセンスの管理とコンプライアンスの徹底
- TSOLogic:クラウド化検討に向けたTCOアセスメント
- Windows ワークロードのスケールが可能
-
Windows オンプレのAWS移行
- 認証基盤:Amazon Directory Service for Active Directory:AD移行:3パターン
- オンプレAD直接参照
- オンプレをDCレプリカ
- AWS AD信頼関係
- AWS Server Migration Service
- VM環境を分析、S3へAMIとして保管、AMIを展開して移行完了
- 無償で利用可能
- 認証基盤:Amazon Directory Service for Active Directory:AD移行:3パターン
-
運用管理の効率化
- AWS SystemsManager
- パッチマネージャー:Windows インスタンスへのパッチ適用
- Amazon CloudWatch
- ログファイル:Windowsのシステムログ等も保存可能
- 最大10年間ログを保持
- 集約・分析
- ログ保持のためのストレージ料金のみ
- AWS SystemsManager
Serverless/AppSync によるモバイル開発の今
-
サーバレス
- インフラ管理不要
- 自動スケール
- 価値に対して支払い
- 高可用性・セキュア
-
Serverless APISs
-
Serverles ビジネスロジック
-
Appsync
- GraphQL API
- シングルエンドポイント
- クエリであり、
- QUERY
- MUTATIONS
- SUBSCRIPTIONS
- 様々なデータソースおよびAPIにデータ動機や連携機能を提供
- GraphQL API
-
リアルタイムデータ伝搬
- AWS Lambda経由でAppSyncを通してデータ連携
-
グノシースポーツ
- 8月開発開始、10月リリース
- AppSync
- フルマネージドGraphQLサービス
- PubSubによるリアルタイム更新
- なぜ?
- リアルタイム更新
- DynamoDBに初回書き込むだけでその後はLambda経由で自動更新
- スキーマファースト
- API仕様書書くことのコスト
- AppSYncはスキーマ定義→データファーストの流れしかない=スキーマファーストしかない
- RESTだとつらいネストされたデータ取得
- バックエンドエンジニアはデータアクセス方法だけを提供
- フロントエンジニアが必要なデータを選択
- リアルタイム更新
-
amplify+React demo
-
amplify によりAppSyncスキーマに自動追加
AWSを活用したユーザー認証実装パターン解説
-
エンドユーザ(カスタムアプリ利用者)に対する認証
-
AWSの認証関連マネージドサービス
-
ユーザ認証に関連する関心事
- 強固な認証
- ユーザビリティ
- ガバナンス・コンプライアンス
- 構築・運用性
-
AWS Single Sign-On
- 複数のAWSアカウントやビジネスアプリへのSSOを実現
- MFA
- パスワードポリシー
- SSOによるユーザビリティ向上
- AD対応
- CloudTrail対応
- プログラミング不要
- マネージドサービス;負荷軽減
- 複数のAWSアカウントやビジネスアプリへのSSOを実現
-
AWS Directory Service
- マネージド型MS AD
-
Amazon Cognito
- カスタムアプリやAWS APIの認証・認可
- MFA
- パスワードポリシー
- AWS Credentials
- ソーシャル連携
- 外部IDプロバイダ連携(SAML2.0)
- CloudTrail対応
- プログラミング不要
- マネージドサービス;負荷軽減
- ユーザプールとIDプール
- カスタムアプリケーションでの利用:ユーザープール
- AWSのサービス利用させたい’:IDプール(AWS Credeitials発行)
- カスタムアプリやAWS APIの認証・認可
-
WEBAPPの実装例
- 従来型HTMLベース
- Application Load Balancer
- ALB + ユーザプール(Amazon Cognitoの活用)
- ALBからAmazon Cognitoのユーザプールへリダイレクト→認証後ALBへ再度リダイレクト
- ALB不使用(NLB)の場合:アプリで自前で認証
- ALB + ユーザプール(Amazon Cognitoの活用)
- Application Load Balancer
- モダンAPIベースWEBAPP
- APIをAamzon API Gatewayで提供している場合、以下のサービスで認証可能
- cognito
- IAM
- Lambda
- Cognito活用時
- ユーザープールからToken返却→APIGatewayで通貨可
- IDプールを利用する場合、「ユーザ認証」情報を利用してAWS Credentialsを発行
- Credentials:事前にIAMロールの割り当てルールを設定
- デフォルトロール・ルールベース・トークン内指定・未認証
- Credentials:事前にIAMロールの割り当てルールを設定
- ※AWS Amplify
- APIをAamzon API Gatewayで提供している場合、以下のサービスで認証可能
- 他ベンダーとのシングルサインオン:AWS SSO
- 100種類以上のアプリ・SAML20対応のアプリを統合可能
- オンプレのActive Directoryも連携可能
- 従来型HTMLベース
ビジネスを加速するAI活用 - Amazon Forecast と Amazon Personalize
-
DXにAIを活用するための新たなスタック
-
ML Framework
-
ML Services : Amazon SageMaker
- モデルの作成を短期間化
-
AI Service
- Amazon Textract
-
-
Forecast(Preview)
- 自動化された時系列データ予測サービス:Amazon自身が利用
- 機械学習経験不要
- 過去履歴データなどから、多くの課題に適用可能
- 需要予測・人員予測・経済指標・在庫計画・・・
- 15%の予測精度の向上は純利益を3%改善させる
- 実世界での予測は複雑
- 季節性や外部要因・履歴データの欠如・・・
- データに対応したDLモデルを5ステップでモデル作成可能
- Amazon独自のDL予測アルゴリズム
- 3つのDatasets
- target time-series
- related time-series
- Item metadata
-
Personalize
-
リアルタイムパーソナライズとレコメンデーションサービス
-
機械学習経験不要
-
データドリブンな意思決定
-
正しいレコメンデーションには正しいモデルが必要
- 音楽・本・映画・・・それぞれで異なるモデルが必要
-
クラウドにおけるアーキテクチャの設計原則
-
webアプリにおける実践を通じて、この原則を理解する
-
基本中の基本
- Shared VPCではVPC環境を複数アカウントで共用可能
- ネットワーク構築アカウントとアプリケーション担当アカウントで共用
- Shared VPCではVPC環境を複数アカウントで共用可能
-
Architecting for the cloud 2019
- 障害を見越した設計
- 冗長化
- 障害の検出
- ダウンを検知しアクションを起こす/起こさないの判断
- 永続データストレージ
- 消えてもいいデータもあるのでは?
- 複数データセンターを用いた自動復旧
- AZを使う
- 全レイヤでのセキュリティ実装
- 徹底的な防御
- 弱いところから守る、という考え方もあるが、できるところはとにかく防御するべき
- AWSのセキュリティサービスを積極的に使用する
- 特権アクセス制限
- リアルタイム監査
- 徹底的な防御
- ストレージの選択肢活用
- S3
- EC2+EBS
- Elastic File System
- 伸縮性の実現
- ブートストラッピング or Golden Image
- 空のイメージからブート時にストラップ
- または自らのGolden Image
- 家畜として扱う(ペットではない)
- 替えがきくということ ペットとして大事に育てるのではなく、いつでも替えがきく
- サービス継続性の重視
- ブートストラッピング or Golden Image
- 並列で考える
- 1台で100時間=100台で1時間
- なめらかなスケーリング
- 障害影響範囲を小さく
- ソフトウェアの書き換え
- 疎結合はあなたを楽にします
- よいインターフェース定義
- サービスディスカバリ
- SQS
- 対応できないときの非同期処理
- 失敗時の適切な処理
- 制約を恐れない
- 制限には理由がる
- デフォルト20インスタンス制限
- 提供できるものを計画する
- 今できるものにトライする
- うまくいくものを出荷する
- できるときに出荷する
- 繰り返し繰り返す
- 制限には理由がる
- 実践
-
セキュリティは常に最優先
- 必須:アカウント要不要と権限管理、証跡
- IAMユーザ・グループの設定
- CloudTrail,Config,GuardDuty,Security Hub、MFAの有効化
- Enabling and Disabling Regions
- https://aws.amazon.com/solutions/aws-landing-zone
- 必須:アカウント要不要と権限管理、証跡
-
セッション情報は外だし
- スケールさせやすく
-
Amazon SQSを挟んで、Frontend とBackendを疎結合に
- DBの処理が終わるまで待つ必要ある?Queueに任せれば?
-
計算資源を使い捨てるために
- ブートストラップ
- Golden Image
- コンテナ:ECSのDockerサポート
- Infrastructure As Code
- Cloudformation opsworks
-
CloudFront
- S3への直接アクセス禁止にする
- 防御レイヤとして追加:DDos対策
- さらにWAF,FirewallManager
- さらにさらにShield,Shield Advanced
- DDos対策用にCloudFrontの前にできるだけ重ねる
-
- 障害を見越した設計