diary2019-12-01CDKでEC2のBlue/Greenデプロイをするパイプラインを作るこんばんは@manoです。12月ということで、今年もNewsPicksではアドベントカレンダーをやります!(って、僕は初参加なんだけども。2019の1日目の記事ということになります。最近CDKばっかり触っているということもあり、当ブログとしてはここまで2記事連続でCDK関連の話をしてきましたが、今日もCDK関連の話をします。NewsPicksでは現在、デプロイフローの見直しを進めています。Tomcatといったwebサーバー構成でアプリケーションを動かしています。今後それをコンテナ化したり、大きなモノリスになってしまっている部分のマイクロサービス化などをどんどんやっていこうと思っているのですが、まず着手しているのがデプロイフローの改善です。groupのBlue/Greenデプロイを実現しています。これを、CodeDeployを使用してBlue/Greenデプロイを行うようにしようとしていて、そのあたりの仕組みの実装方法にCDK(言語はtypescript)を採用しています。書かなければならないコードの量が少ない。CloudFormationだと、一つ一つのコンポーネントには基本的にroleの明記が必要で、一つのyaml(またはjson)ファイルが巨大になっていくこともしばしばかと思います。その点、CDKではコード内の依存関係から、ある程度勝手に必要なpolicyが割り当てられたroleが自動的に作成されます。IDE等でclassやinterfaceの定義にジャンプすれば、ドキュメントを見ずとも開発が可能CloudFormationだと、yamlやjsonに書いていかなければならないため、自身でドキュメントを確認し、適切に書かなければいけません。CDKだと、typescript等の型のある言語を選択すれば(というかtypescript以外で書いたことないから他はよく知らないんだけど)、classやinterfaceの定義にジャンプすれば必要なパラメータがどのようなものかがすぐにわかるため、便利です!また、テストが書けるというのもとても魅力的です。「デプロイして初めて書いた内容が合っているのかどうかがわかる」という局面も少なからずありますが、テスト実行時点でわかるものも結構あります。CDK自体の開発がものすごく活発これも大きな理由です。最近だと毎週のようにバージョンが上がっています。新デプロイフローの構成このような感じで進めています。tagがbitbucketにプッシュされたらCodeBuildプロジェクトがビルドを実行する1の成果物がS3にアップロードされる2のbucketにアップロードされたことをトリガーとして、CodePipelineが走る2でアップロードされた成果物を整理してS3に上げ直す手動approveCodeDeployによりBlue/Greenデプロイを実行するという構成にしています。上記構成のCDKでの実装このような感じで実装しています。GroupがCDKでは実装できません。roleだけを作っています。create-deployment-group等で行う必要があります。手動approveステージが作れる例えば「ビルドまでは完了してあとはデプロイだ」というとき、そのままデプロイが走ってしまうと、万一それがよからぬタイミングだったりすると大変です。approveという機能があり、手動でapproveしないと以降のステージには進めないようになっています。CodeDeployが使える後述しますが、CodeDeployが素晴らしいです。CDKによりコードで管理できる素敵ですね。groupがまだ生きていればすぐにrollbackできるし、terminate済みだとしても簡単に戻したいリビジョンを選択肢リデプロイできます。細かいイベントフックごとに任意の処理を実行できるこちらに詳細が書かれていますが、デプロイ中のフックが結構細かく分けられていて、それぞれに任意の処理を挟むことができます。終わりにアドベントカレンダーというものに初めて参加したのですが、記事を強制的に書かざるを得ないという意味で貴重な機会だなと感じました。これを機に、様々なカレンダーにどんどん参加したいなと思いました。2019-12-02追記アドベントカレンダー2日目の記事です。Managerを使うことが主流となり、bastionの出番は減ってきたと思うが、CDKでbastionを作ったので手順をしたためておく。pairをコンソールから作っておく。手順はこちらを参照してください。"(ダウンロードしたpemの中身。改行コードを\nで置換したもの)"}という形で登録しておく。Mangerについてはこちら。例によってlibのファイルのみ載せておく。binはまぁご自由に。gist.github.comポイントは下記の通り。subnetにbastionを作ること。Managerを使ってローカルマシンからbastionにアクセスする。ec2-user(必要ならね)(これができるんだから、bastionなんかいらなくね!!??という疑問はもっともである。connectで自分の持っている公開鍵を一時的にbastionに登録してsshで繋ぐ。Managerから取得するpemの中身は、改行コードを実際の改行状態にしておく改行も含めて鍵。Groupは、他のstackでも使うだろうからエクスポートしておく今回はallow-from-bastionという名前でエクスポートしておいた。pairのpemをセットしておく他にいいやり方知ってる人がいたら教えてください。session-startで繋げるのでbastionいらずになります。Disassemblerで、CloudFormationのyamlをcdk化してみた久々の投稿であることには触れずに本題をw最近CDKを触る機会が多いので、記事を書きやすいトピックを探していたのだが、おあつらえ向けのものがあったので書きます。こんなものがあります。jsonを喰わせると、よしなにCDKのコードにして吐き出してくれるよ!」というやつ。どんな感じに出力されるのか興味があったが、最近ついにこれを触る機会が訪れた。CDK化する対象はこれ。CDKに変換するツールなので、このままだと使えない。yamlをjsonに変換するツールを使ってなんとかjsonにする。!Ref関数などがことごとくnullになってしまう。この辺をなんとか頑張ってjson化する。json化すると(きっと)こうなる。cloudformation-stack.tsすると、こんなファイルが出来上がる。}}うーん、やはりまだ安定番ではないだけのことはあってすごいコードだ・・・。deployが通る状態になるまで、手で修正するしかない。「どのクラスを使うか」というのは網羅しているので、愚直に直していく。Parametersは固定値にした。サイトリライアビリティエンジニアリング」の、今日は3章を見ていきます。この章は冒頭でこのように書かれており、非常に重要な章であることがわかります。「SREの仕事とはどういうものか」、そして「なぜそのような仕事をするのか」についての幅広い見地を得たい方にとっては、最重要となる必読の章です。この章では、大きく4つのことが書かれています。一つ一つ、いつものように雑にまとめてみましょう。信頼性のないシステムは急速にユーザーの信頼を失うことになるので、可能性を減らすためのコストは支払う必要があります。このコストには2つの特徴があります。コンピュートリソースのコスト設備の冗長化にかけるコスト。機会のコストリスクを減らすためのシステムや機能を構築するために組織がエンジニアリングリソースを割り当てることから生じるコストSREでは、サービスの信頼性を管理する大部分は、リスクを管理することによって行います。下記2つは、等しく重要なポイントです。システムの信頼性を高めるためにエンジニアリングを見いだすこと動作させるサービスの適切な障害許容レベルを定めることサービスを十分信頼できるものにするための努力はしつつも、必要以上に信頼性を高めようとはしない、というのも重要なポイントです。サービスリスクの計測Googleが注目している客観的なリスク検知のメトリクスは、計画外の停止時間です。この計画外の停止時間は、サービスの可溶性に求められるレベルによって把握できます。Googleのように24/7で世界中のどこかからサービスのトラフィックを少なくとも一部を提供している可能性が高いとなると、時間を基にしたメトリクスは意味を持たないので、リクエストの成功率の観点から可用性を定義しています。このサービス可用性のターゲットを四半期単位で設定し、そのターゲットに対して週単位、もしくは日単位でパフォーマンスを追跡しています。サービスリスクの許容度サービスリスクの許容度を特定するためには、SREがプロダクトのマネージャーと共同で作業を行い、一連のビジネスゴールをエンジニアリング可能で明確な目標に変換する必要があります。この共同作業は、現実には簡単ではなく、本の中ではコンシューマサービスとインフラストラクチャサービスの場合で分けて解説されていますが、共通するリスク許容度の評価に関しては、以下の4点が挙げられています。エラーバジェットの活用プロダクト開発者のパフォーマンスがプロダクトの開発速度で主に評価されているのに対し、SREのパフォーマンスはサービスの信頼性を基にして評価されます。そのため、この両者には本来的な緊張が存在していますが、エラーバジェットはこの緊張を客観的に解消することのできる手法です。エラーバジェットは、Googleでは以下のように形成されます。プロダクトマネージャーがSLOを規定。実際の稼働時間は、中立な第三者であるモニタリングシステムによって計測この2つの値の差異が、その四半期内の「損失可能な信頼性」という「予算」の残分となる計測された稼働時間がSLOを超えている、言い換えればエラーバジェットがまだ残っているなら新しいリリースをプッシュできる非常にわかりやすいですね。これなら社内政治等のわかりづらい手法で両者の対立が激化することなく、プロダクト開発とSREとのバランスを保つことができます。エラーバジェットが枯渇したタイミングで、どうしてもその四半期内に追加のプロダクト開発を行いリリースをプッシュしたいときは、SLOを緩和することによってエラーバジェットを増やす、という選択肢を取ることもできます。まとめサービスの信頼性管理の大部分はリスク管理に関係することであり、リスク管理には多くのコストがかかることがある信頼性のターゲットとして100%が適切であることはほぼありえない。昨日ポエムだったので、今日もポエムを書こうかとも思ったんですが、それだと一体なんのためにやり始めたのかさっぱりわからなくなるので、やっぱりやめました。SREの観点から見たGoogleのプロダクション環境1章からガラッと変わって、2章は非常に具体的にGoogleのデータセンターで実際に稼働しているシステムについて語られています。正直に言いますが、この章、難しすぎて全然わかりません↑この感想だけで終わりたいくらいだけど、それだとポエム以下になるのでまぁもう少し書くけれども・・・。わかったところを箇条書きにします。間違っている可能性しかないです。Network)アーキテクチャであるB4で相互接続されているハードウェアを組織化するシステムソフトウェアマシン群の管理を行うBorg複数のレイヤーから構成されているストレージ低価格だが高速に動作する「ダム」スイッチングハードウェア等を使って構築しているネットワーク複数箇所のデータセンターにまたがって扱うロックサービスのChubbyソフトウェアインフラストラクチャすべてのサービスは、Stubbyと呼ばれるRPCを使って通信(StubbyのオープンソースバージョンとしてはgRPCがある)開発環境ソフトウェアのビルド時、データセンター内のビルドサーバーにビルドリクエストを送るコンパイルは、多くのビルドサーバーが並列に行うため、大規模なビルドであってもすぐに実行されるpush-on-greenシステムで、テストをパスした新バージョンが自動的にプロダクション環境に送られるプロジェクトもあるその後、サービスがGoogleのプロダクション環境にデプロイされる様子がわかりやすく例を用いて書かれています。ま、きっとこの章は今後何度も読むんだろうなきっと。SREの観点から見たGoogleのプロダクション環境Tweet広告を非表示にするもっと読むコメントを書く2019-07-18毎日技術的なことを書くはずが・・・今日はショートポエムちょっとわけあって、昨日の続編が今日は書けません。明日は書けるかなぁ・・・再開は明後日な気がしますね。今日はショートポエムを一つ。先週から、キックボクシングジムに通い始めたのですが(この系列のどこかに通っております)、結構きついんですよ、カリキュラムが。1分間サンドバッグを打ちまくってはちょっと休憩してまた1分打ちまくる、みたいなことを何度も何度もやるんです。そのとき、あーすごくこれって大事だなって思ったのが、とにかくその毎ターンを全力でやる、ということ。いろんなところで手を抜こうと思えば抜けるんですよね。パンチをのろく打ったり、各動作間のインターバルを少しずつ増やしていったり。「もうこの1分の後にどうなってもいい!とにかく毎回フルパワーでいくんだ!!」って思いながらやると、意外とサボらずともいけちゃったりする。サボったときと疲労感もそこまで変わらないのに、全力を出し切ったときの方が、いろいろと得られるものが多く感じられるんですよね。なんか、これが僕にとってはとても新鮮な感覚で。これって他の様々なことにも言えると思って。仕事も、家事も、どっちにしろやらないといけないし、どっちにしろ疲れるんだから、全力でやると。これが大事なことなんだなと。いう、以上今日はショートポエム回でした。微妙にお酒が入って、ものすごく眠い中書いております。サイトリライアビリティエンジニアリング」の1章について書きたいと思います。イントロダクションイントロダクションなので、これ先この本にどのようなことがかかれているのかというのがまずは網羅的に紹介されています。イントロダクションの時点ですでにおもしろいし、勉強になる!どんどん先を読みたくなります。そもそもサイトリライアビリティエンジニアリング(SRE)とは、Googleで培われたシステム管理とサービス運用の方法論です。こちらの本では、実際にGoogleにおいて、どのような理念に基づき、具体的にどのような手法で運用されているのかということが書かれています。全部で547ページ!大作です(索引込み)。Googleで誕生したSREですが、Google社では「SREメンバーの作業における50%は、エンジニアリングであること」というルールがきっちり決まっているそうです。緊急のオンコール対応や、手作業のルーチンワークみたいなことは、必ず全体の50%以下の時間で行わなければいけません。それを超えないように、SREはがんがん自動化していくのです。その結果が、たとえ複雑なものとなろうとも。あるサービスがなんらかのSREメンバーが行う手作業に依存してしまうと、そのサービスがスケールしていくごとに手作業の量もどんどん膨らんでいきます。ならないよう、個々のメンバーの作業内訳をしっかりと計測し、エンジニアリングが50%を下回ってしまうようなときにはなんらかの手を打つわけです。僕がここでとても興味があるのは、「どのように個々のメンバーの作業内訳を計測しているのか」という点です。メンバーが日報などで、「あー今日何やったかなぁ」などと振り返りながらやるのは非常に面倒だし、僕ならそんなことを毎日やりたくはありません。第一、正確に計測できているとも思えません。この先を読むと出てくるのか、それともそこについては各チームで工夫すべきところなのか。先を読んでみたいと思います。なんかこの部分を読んだだけでも、これまで僕がやってきたことを振り返ってみて、手作業が多かったなぁ俺・・・と落ち込みました。デプロイとか、おかしなインスタンスにはアクセスが行かないようにして・・・とか、もっと自動化しちゃえばよかったなぁ、と。1章はイントロダクションなので、さらっとこんな感じですかね。SREの観点から見たGoogleのプロダクション環境を見ていきたいと思います。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。