AWS Summit Tokyo 2018、今日で最終日です。
各公演を聴きながらメモった内容です。
そのうち公式に動画やプレゼン資料がアップロードされるはずなので、そちらも是非！
[10:00-10:40] Day 3 基調講演
レコメンデーションシステムのようなパーソナルな情報はたくさんの過程をたてて実際にテストする必要がある：クラウドサービスに向いてる
Amazon Goという実店舗はVideo Drivenの機械学習型の分析処理システム
機械学習の新しいモデル：Amazon SageMaker
今日から東京リージョンで使えます
機械学習のF/Wを組み込めるよ：Chainerとかね
dely株式会社
- パーソナライズしたレシピの提案してます
- 機械学習が必要だと思いAmazon SageMakerを導入
- フルマネージドな機械学習のフレームワーク
- モデル選定、構築、ビルド、デプロイまでが一気通貫でできる
- 自分に似ている人の好みは、自分も好みのはず！という仮定をたてて最適化した
------
ある程度のパッケージが揃ってる
- video rekognition
- スピーチとヒアリング
- テキスト処理、形態素分析、翻訳 など
詳しくはこちら → https://aws.amazon.com/jp/machine-learning/
Amazon Aurora：AWSの歴史上もっとも急成長している
- MySQLやPostgreSQLと互換でコストは1/10
- multi master構成をDCまたいでできる
- Amazon Aurora Serverless
- Amazon Aurora Backtrack：特定の時間へ巻き戻し可能
- 反復するテストには最適
S3はデータレイクの用途でもっとも多く使われている
- エクサバイトのデータがある( 1,000,000,000,000,000,000バイト = 1,000の6乗 = 10の18乗 )
リクルートテクノロジーズ
グループ従業員4.5万人
- 扱うデータとして、自然に発生するものと、意図的に貯めているものがある
- オンプレミスもクラウドもたくさん
- オンプレだと時間とコストがかかるから、まずはクラウドでざっくり知見を貯めるのはいい使い方だと思う
- Amazon QuickSightが昨日から東京リージョンで使えるようになってたので早速いれてみたよ（ビックデータの分析結果を多数の視覚化グラフでリアルタイムに見れるフレームワーク）
- データさえちゃんととっておけば、いくらでもツールを試せるし時間も早いしコストもあかkらないのはクラウドの強み
------
AWS Well-Architected Framewark
データをどのようにフェイルオーバーしてますか？
DCに置いておくよりクラウドの方が安全というのが常識になりつつある
ATEAM
- エンタメ（ゲーム、アプリ）、ライフスタイル（Qiitaとか）、EC事業
- インフラの対応は会社の成長を阻害してるはず → AWSに載せ替える
- ユーザ分析にSageMaker使ってる
------
セキュリティの監査は自動で常にセキュアな状態を確保する時代
イノベーションの速度にセキュリティの速度は追いつかなければならない
AWS CloudTrail：利用状況のログ作成
- システムがコンプライアンスが取れていることが確認できる
その他、Well-Architectedを準拠するためのツール、サービス群
- AWS Config Rules
- AWS KMS
- Amazon Secrets Manager
- Amazon Certificate Manager
仮装マシーン
- EC2：4TBものメモリを積んだものもあるし、数時間だけいろんなリージョンでとかもできる
- ECS、EKS：コンテナの管理
- AWS Fargate：管理不要、コンテナレベル、東京リージョンでは2018年7月から利用可能
- サーバレス
株式会社ソニー・インタラクティブエンタテインメント
- PlayStation作ってる会社です（~2016 / Sone Computer Entertainment）
- PlayStation Networkとは
- PS向けのネットワークサービス
- 設計思想：Core or Context
- 本当に必要なビジネスドメインにフォーカスするため、それ以外の部分は外部に出す
- AWSもそのContext
- サーバレスは使いやすそうなところから開始
- コンテナは組織をあげて総動員
- サーバレス
- cron job / event driven / stream processing / custom logic
- nodejs / java / python
-------
[13:00-13:40] AWS におけるコンテナ管理 ～Amazon ECS / AWS Fargate～
ECSとAWS Fargateの考え方やデザインについて
コンテナ管理に必要なもの
- なぜコンテナ？
- パッケージングでコードをすべて含めて→配布が容易に→イミュータブル
- アプリケーションの開発に集中したい
- Docker Containerを使うのは簡単だけどサービスに組み込むとなるとコンテナの管理ができなくなる
- 数もホストも・・・
- ECS（Amazon Elastic Container Service）
- EC2を立ち上げてその中にTaskを配置する
- Task：アプリケーションを構成するコンテナ１つ以上
- Container Instance：Taskが起動するEC2インスタンス
- Service：Taskの数を管理
- AWS Fargate
- Container Instanceを管理しなくてよくなる
- Taskのみでスケールしていく
- サービスディスカバリ
- マイクロサービスで疎結合にするのがベストプラクティス
- コンテナを利用する動的な環境では接続先を自動で探して繋がる必要がある
- 基本はALBでpathベースでルーテイングする
- ALBの下に複数のservice / workerを起動する
- ECS Service Discovery
- FQDNでアクセスさせる
- Taskの状態をチェックしてRoute53にアドレス登録する
- ロギングとモニタリング
- コンテナアプリケーションのログはSTDOUTに出力するのがベストプラクティス
- ローカルの開発環境でもデバッグが容易
- CloudWatch logに入れるのがよし
- 既存のファイル出力されてるサービスについて
- アプリケーションコンテナとロギングコンテナの２つのContainerをTaskにいれる
- アプリケーションコンテナからロギングコンテナに出力してロギングコンテナが外部にログを送る（サイドカー構成）
- Event Streamによるリアルタイム検知
- ECSクラスタの状態変化を検知
- 通知だけならSNS連携
- 処理が必要ならLambdaに
- セキュリティ
- アクセス権限は基本IAMロール・ポリシー
- クラスタに対しての権限、アプリケーションの権限、ECS
- EC2に対してのロール/ポリシーと同じ
- パスワードってどうやって渡す？
- ParameterStore、SecretsMAnagerを利用する（裏はKMS）
- 管理が必要となるレイヤー
- ECSならEC2インスタンスの管理が必要
- FargateならEC2インスタンスのスケーリングを考えなくてよくなる
- 増えたTaskの配置はどうなる？
- CPU、メモリー、ポートの割り当てとかが必要
- AZ、インスタンスタイプ、AMI
- 配置戦略を満たすか
- 例）t2.micro or t2.smallにCPU使用率60％を維持しつつAZがus-east-1dじゃないところ
[14:00-14:40] PlayStationTM Network での Container 導入事例
コンテナとCI/CD
- dev, ops, secが別々で、開発ーbulidーリリースで1日かかってて、サーイスが100個あったので・・・・
- 速度にフォーカスした！1日に100回デプロイしたい！
- コンテナの作成、管理、リリース、セキュリティまでを一貫して提供
- 必要最小限のもののみを提供
- １０行のコードを書いても、書いた時点で運用がはじまる
- Well-Architected Framewarkは優秀
- スケールインは慎重に
- CPU使用率が減ったからといってコネクション数が多かったら・・？
- 本番環境へのデプロイツールは独自実装
- 承認とか監査とか、オートスケールとか信頼性などを考慮
- Dockerは役割が曖昧になる
- OSやMWが混ざる
- チームは融資を募ってやったのでモチベーションが高くよかった
- 一番初めからDev、Ops、Sec、AWSの人全員を巻き込んで進めた
- 毎月DemoDayをしてレビューもらった
- 学習コストが高いので学習支援やハンズオンやった
- リスクはとるものではなくて、小さくして管理して進めるべし
- 小さいところから段階的にリリース
- 初めは余剰キャパシティを多めに設定してオートスケールは設定しなかった
難しさ
- ラップトップでの開発速度はあがらない
- CI/CDは早くなるけど
- 調査するときにメトリクスやらログやら見るところが多くなった
- コンテナの依存するものもコンテナで作る必要があって結構ツールやら依存コンテナを作る必要があって疲弊しがち
未来はわからない
- 変化は受け入れた方が良い
- 作りすぎないこと
- 捨てる勇気を持つこと
- マネージドサービスがあったらそっちに載せ替える
- なんでも人の流れが必要
More Dev, Less Ops
[15:00-15:40] gumi が目指す「 Less DevOps, More Code 」~運用を削減して, もっとコードを書こう!~
- インフラチームが一人だったころから現在に至るまでの道のりについて
- 鶴の一声でオンプレ全廃止でAWSに
- AWSは専門家が全部やるので安心？
- 一人では無理ゲー
- インフラ運用の専門チームを構成
- タスク管理とドキュメント作成を頑張る
- チームなのでタスクは分散できたけど、事業が大きくなって忙しくなる→属人化、遅れ始め、残業で賄う
- プライベートチャットでタスクが増える
- チケット化、プライベートチャット禁止、サービス毎に担当者を立てて、しっかり背景を汲むようにする
- 運用チームに開発紗を投入してcodeを書くようになった
- 管理者の負担が増大、なんでも上司に聞かないとわからない状態になる
- メンバーに権限がなくなり、ヘルプできたエンジニアがなにもできずに帰る、、マンパワーに頼り始める
- 横展開する？管理者の負担が増えるのは経験済み。Dev, Opsを同じチームにいれちゃう？技術差がでちゃう
- そこで、環境を整えて社外から招聘して、権限渡した
旧環境との戦いが残ってる
ノード化の罠もあり
ツールの選択のコツ
- 実験的であること
- 他社との比較を必ずすること
- 導入環境毎に合っているかを考える
コードを補う
- CloudFormationを素直に使うと、テンプレが増えて管理できなくなる
- gopher君がうまいことやってくれるランナー
- Ansibleはsshログインなので鍵管理が大変
- 何台かは失敗するよね？→これはオンプレ脳
- EC2を作っては捨て作っては捨てを繰り返せばいい！
- 人の判断が必要なところをコード化すると結構大変になる
- 隙間を埋めるためにコードを書くぐらいがいい
実験的であること、失敗から学ぶこと
[16:00-16:40] NTT データのデジタル融合アプローチ ~ Legacy Digital Integration ~
- Traditionalは、会計や財務など堅牢で守りのIT
- Digitalは、ソーシャルやモバイル、IoTなど攻めのIT
- この２つの領域は、相反するものではなく、シームレスに連携を取れるようにお客様に提供できるように
- システム開発はWaterfallとAgileの適材適所
- Traditionalは、Waterfallが多い
- Digitalは、Agileが多い
- シームレスにつなぐ手法の一つはAPIでつなぐこと
- 例）銀行の資産（Traditaional）をAPIで外部サービスとつなぐ
- REST APIでSwagger使ってる
事例：NTT docomo ~dエンジョイパス~
- 裏の期間システム、データにつなぐTranditional領域は高品質が求められるため、Waterfall
- エンドユーザのUI部分のDigitalの領域は素早い変更が求められるため、Agile
- TranditionalとDigitalの間のAPIに修正、変更がなんどか入ると全体がのびる
- JenkinsでCI/CD実現したので、自動でデプロイできるようにしてるので、リリース後も安全にリリースできる
- CloudFormationに高信頼性のインフラの設計を管理させた
Agileチームにするためのポイント
- 水平なチームコミュニケーション
- 契約関係を気にするとコミュニケーションがしずらいので、メールはやめてすべてチャットで
- 属人性の排除
- ペアプロして知見を分散させたり、Wikiを活用
- 自立と成長
- 自己組織化
- レトロスペクティブ
- 振り返り、KPT
0コメント