昨日は AWS DevOps祭り 2018（2018 年12月3日開催） に参加してきました。
場所は、AWSの新しい目黒オフィスである 目黒セントラルスクエアの21F会のスペース。
AWS Loft以外の場所に入るのは初めて！(笑)
しかし、会場、メチャ広いな。。。
目次
AWS DevOps祭り 2018 とは
イベントの概要を引用します。
AWSを利用したDevOpsを実践する上で役に立つ情報を集めたAWS DevOps祭りを開催します。AWS CodeシリーズやAWS CloudFormationのre:Invent アップデート情報、AWSにおけるDevOps事例の紹介を行います。
まぁ、そのまんま、ですね。AWS を使って構築する DevOps 環境などについて、情報を共有してもらえる有り難いイベントです。しかも無料！
セッション
セッションのメモを書きます。資料は公開されたら追加します！
とりあえず会場でもらった水の写真(笑)
セッション1：AWS Management Tools サービス アップデートのご紹介
アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクト大村 幸敬 さんの発表。
AWS CloudFormation などの AWS Management Tools 関連サービスの最新アップデート情報をどこよりも早くお伝えします。
AWS Management Tools サービス アップデートのご紹介
メモ：
直近3ヶ月からre:Invent2018までのアップデート
１，DevOpsとAWS Management Tools
- デリバリのパイプライン
- フィードバックループ
- ムダやボトルネックを取り除くことでライフサイクルを効率化
Metrics For DevOps
- 作り始めてからデプロイされるまでのストリームが重要ストリームのベロシティをどう改善するか
ベロシティ向上の阻害要因
- 不安
ベロシティ向上のために自動化を
- すべてを自動化する
- どんな手順でも明確にされ自動化することは可能
オンプレミスでの開発の一般的な体制とスケジュール
- インフラと開発のチームが別
- 開発のプロセスが長い
- オンプレはハードウェアがあるから仕方ない
クラウドに持っていくとどうするか？
- そのまま持っていくとあまり変わらない
アプリ開発とインフラが違うチームだと結局ダメ
→アプリとインフラ、運用を合わせてチームにすればいい。アカウントの管理
- コスト管理
運用のやり方は？
アカウントのガバナンスと洗い出しをやるチームを作れば？
運用における2つの選択肢
- 分散化とガードレール ←早く進めるにはこちらが望ましい
- ロックダウンと事前承認
クラウドを活用したDevOpsのポイント
- ビジネスチームがアプリ・インフラ・運用を担当
- 共通基盤・運用チームはパターン化した環境の提供と
２，AWS Management Tools
- Provisioning
- Configuration
- Monitoring
- Operations and
AWS Cloud Foramation
アプリ形態によるデプロイ対象の違い
- コンテナのほうがユーザーが管理すべき部分が少なくなるので楽になる。
- サーバーレスも同様
AWS Service Catalog
固定のベストプラクティスを作成できる
AWS OpsWorks
- マネージドなコンフィグレーションサーバーを提供
- ログ
- 継続的記録、継続的アセスメント
AWS CloudTrail * アカウント
AWS Systems Management
アプリとインフラのパイプライン
３，各サービスの使い所とアップデート
CFn - テンプレート開発のサポート
cFn-lint サービスとしてのチェック
cfn-nag
セキュリティ関連のチェックTaskcat
様々な環境で動くかをチェックCloud Development Kit
DSLs
色々な言語でDSL- 色々なもののサジェストが出るようになった
cform-VSCode
- 雛形コードを自動生成
CloudFormationでスタック差分の検出機能をリリース
- CFnで作成したリソース状態と現状との差分を検出できるようになった
- スタックをデプロイをしたあとで手動で実施した変更作業によって発生した差をチェックできる
- 現状ではサポートリソースに制限あり
Macros
- テンプレートの標準的な機能では実現できない処理をLambda関数を呼び出すことで実現
- 検索や置換などの単純な操作からテンプレート全体の変換をできる
Dynamic Reference
- 他のサービスに格納されたデータを動的に参照
パラメータストアの参照
- セキュアストリングの参照もできるようになった
AWS CDK
- 開発者プレビュー
- Java、C#、TypeScript、JavaScriptをサポート
- Pythonはまだ
Systems Manager
メンテナンスウィンドウを定義して各種オペレーションを実行できる
サーバー上のコマンド実行
- APIの呼び出し
- Lambda関数などの呼び出し
定期的な情報収集
- ステートマネージャー
- インベントリ
- Patch Manager
構成情報など
- パラメータストア
- ドキュメント
リソースグループ
- リソースをグループ化して管理
タグエディタ
セッションマネージャーでマネジメントコンソールからOSへシェルアクセス
- 通信ポートを開放せずにサーバーへのシェルアクセスが可能
- 定期実行はRunCommandで
Automationでの任意の操作を記述可能
- 手順を記述したyamlを実行する
Step FunctionsでAPI呼び出しができるように
- ビジュアルに処理を記述
AWS Systems Managerパッケージ管理機能
- Inventry及びAutomationのマルチアカウント対応
AWS Systems Managerは使ったリソースの代金以外はコスト0円。
- Inventryとセッションマネージャー
４，Monitoring- CloudWatch
インタラクティブなログ分析を実現するCloudWatch Logs Insight
- ElasticSearchを使わなくてもCloudWatchでできる
- 東京も使えるようになっている
- スキャンしたログの量による課金
Automatic Dasgboard
グラフを外部から取得可能に
- グラフの画像イメージをAPIで取得可能
Audit- CloudTrail&AWS Config&Config Rules
５，マルチアカウント関連のアップデート
VPCとアカウント分離レベルの違い
VPCによる分離
アカウントによる分離
PrivateLinkによるプライベートネットワーク経由によるAPIアクセス
マルチアカウント環境におけるガバナンスを強化する
- AWS Control Tower
マルチアカウント管理をするときに便利な機能
クロスアカウントでのリソース共有が可能に
複数のアカウントで1つのVPCを共有できる
Transit Gateway
- 自分でソフトウェアルータを管理すること無く複数のVPCや拠点間を相互に接続・制御する
CFn StackSets
- 一つのテンプレートを複数のAWSアカウント及び複数のリージョンに展開可能
CloudWatch Event Bus
- 異なるアカウントに対してCloudWatch Eventを発行
AWS Security Hub
- アカウントが増えてくるとそれぞれのアカウントで起きている事象を管理するのが難しい
- レポートが作成される。現在プレビューなので無料。
AWS Config Aggregator
- 複数アカウント、リージョンのConfig情報を集約
AWS Systems Manager
- Inventry及びAutomationｂのマルチアカウント対応
アカウントレベルの払い出し管理がより容易に
セッション2：AWS Developper Tools サービス アップデートのご紹介
アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクト 福井 厚 さんの発表。
AWS Code シリーズなどの AWS Application Development 関連サービスの最新アップデート情報をどこよりも早くお伝えします。
AWS Developper Tools サービス アップデートのご紹介
メモ：
re:Invent 2018で発表されたサービス、及びサービスのアップデートの紹介
- AWS Developper Toolsとは
- re:Invent 2018で発表された最新アップデート
- re:Invent 2018以前のアップデート
AWS Developper Toolsとは？
- Source
- Build
- Test
- Deploy
- Monitor
AWS Cloud9
- クラウドベースのIDE
- ブラウザのみでコーディング、実行、デバッグ
- リアルタイムでペアプロを可能
- ダイレクトなターミナルアクセス
- サーバーレスの優れた開発環境を提供
- フル機能のエディタ
- 幅広いランタイムのサポート
- フル機能のデバッガ
AWS CodeStar
- AWS上でのアプリケーションの展開、デプロイ、ビルド
- 様々なテンプレートが予め用意されている
- 裏ではCFnが動いている
- 管理するためのコンソールを提供
AWS CodeCommit
AWS CodeBuild
- フルマネージドのビルドサービス
- 継続的なスケールと同時実行ビルド
- Dockerイメージで提供されている
Code Pipline
- CI/CD
- プロセスのモデル化と見える化
AWS Developper Toolsアップデート
- CodeDeployがECS/FargateへのBlue/Greenデプロイメントをサポート
- 東京でも利用可能
- Blue/Green Deployを実行するにはCodeDeploy IAM Roleを付ける必要がある
- 自動的にBlue/Green Deployのモニターをする画面も自動的に生成される。
- 失敗した場合は元のターゲットに戻る
AWS CodePipelineがECRに対応
re:Inventでのアップデート
AWS CodeCommitがCLIとマネジメントコンソールから操作可能に
AWS CodeBuildで複数の入力ソースと出力を指定できるように
Cloud9でTypescriptのサポートを開始
CDKもTypescriptで開発されている
AWS CodeBuildでBitBucketプルリクエストのビルドをサポート
- WebHook経由でイベント検知
BeansTalkがALBのNLBをサポート
CodePipelineの実行高速化、クロスリージョンアクションがサポート可能に
OpenJDKのLTS
GAは来年の1Q
セッション3：DevOps: 変化の激しい環境でビジネス競争力を向上させる具体的な方法
クラスメソッド株式会社 DevOps支援室 マネージャー 藤村 新 さんの発表。
クラスメソッドでは、お客様の組織における DevOps 支援を目的とした DevOps メソッドというサービスを提供しています。
本セッションでは、DevOps が生まれた背景や歴史、クラスメソッドにおける DevOps の定義、提供している DevOps 支援の具体的な内容とその導入事例、また DevOps を使ってビジネス競争力を向上させる具体的な方法についてお話します。
DevOps: 変化の激しい環境でビジネス競争力を向上させる具体的な方法
メモ：
DevOps=パリス・ヒルトン
- DevOpsとアジャイルと私
- DevOpsもやいする私のもやもや
- DevOps支援室の取り組み
- ビジネス競争力を高める具体的な方法
まとめ
DevOpsとアジャイルと私
2003年くらいからの歴史DevOpsもやいする私のもやもや
5年遅れの葛藤
DevOpsってずるくない？
2017年の数字を見ると頻度を上げることはできたけど、障害の頻度は上がった。
全部DevOpsの手柄になっている
DevOpsって名前が悪くない？
当初はDevとOpsの対立構造解消にフォーカス
DevOpsってなぜ定義しないのか？
XXはDevOpsではないというのが多い。
アジャイルの価値と原則
- DevOps支援室の取り組み
定義なくして支援なし！
定義してみた
変化の激しいビジネス環境において
組織の ビジネス競争力を向上 させること
組織のビジネス競争力を向上させるために行う
すべての活動の総称
単なる標語
DevOps導入のステップ
- リードタイムの短縮
- フィードバックループの継続的な短縮、強化
- 継続的な学習と実験の文化の創出
リードタイムの定義
ある機能を作りたいと考えてからエンドユーザーの届くためにかかる時間
導入大変なので支援サービスが有ってよかった
- ビジネス競争力を高める具体的な方法
VSM(Value Stream Mapping)とは
一番のボトルネックに集中
リードタイムをKPI
具体的な短縮目標を決めて部門横断目標にする
可視化が重要
まとめ
まずはVSMを実施
リードタイム短縮ボトルネックを把握- 聞き取れませんでした。。。
セッション4：事例紹介：テレビ・レコーダーのバックエンドにおける CI/CD への取り組み
ソニーネットワークコミュニケーションズ株式会社 CA3部 Metaサーバーチーム テクニカルリード 佐藤瞬さんの発表。
ソニー製のテレビ、レコーダーにテレビ番組情報や視聴ランキングなどを配信する Meta サービスを運用しています。
本セッションでは、この Meta サービスの運用チームにおける CI/CD の取り組みについて紹介させていただきます。
メモ：
SWFのシンプルアイコンがない
ステップファンクションへの移行をしろってことか？
CI/CDパイプラインの構築
40本作っているコンテナのデプロイ
ALBでBlue/Green Deployをしている。EC2インスタンスのAMI更新
Ansible/Packerで構築Serverlessアプリのデプロイ
など
- Dodepipelineの導入経緯
Code化されたPipelineは存在しなかった
導入してよかった点
- AWSのほかサービスとの連携
困りごと
色々あったけど改善されてきている
現状ワークアラウンド的なことをしている部分
- SourceでGit Tagを指定できない(Branchのみ)
実行時にパラメータ指定ができない
Canary Deploymentへの取り組み
基本的にはBlue/Green DeployだがCanay Deploymentも試験的に実施
- 試験的な位置づけ
- 負荷を見るために実施
App meshが出てきたので再設計したい
継続的デリバリーについて
継続的デリバリーの活動では継続的にデプロイしていくことになる
←リスク
デプロイはリスクでもある
一方でデプロイしなければ価値は上がらない
- リスクの低減
- 信頼できるテスト作成
- デプロイ手法を工夫
- 切り戻し対策
SLI/SLO・エラーバジェット
- エラーバジェットを満たしているかがデプロイに問題がないかの指標
月一回くらいで見直し運用
- まとめ
CodePipelineなどAWSサービスをがっ弦使ってパイイプライン構築
まとめ
別のイベントが有って懇親会の参加はしませんでした。 待合スペースの写真を貼ってくので、雰囲気だけ！
