参加と登壇してきました日記ブログを書くのは久々です。参加と、プラチナスポンサーセッションとして今仕事でしていることをSREと絡めてお話しさせていただきました。sre-next.devまずこの場を用意してくださったスタッフの方々、そして機会を用意してくださった会社の皆様、またスライドを前日遅くまでレビューと意見を盛り込んでくれた同僚に感謝いたします。開発と運用をしておりました。10月か、11月の終わり頃、せっかくだからやっていることをSREと絡めて話してくれないか、というお誘いをいただき、スポンサーセッションの20分の枠をいただきました。監査も重なり、我々のアプリケーションががんばって準拠しつつ、運用を楽にする工夫をしている、この辺りの工夫やハックをSREと絡めれば何か考え方などを聴衆の方々に持ち帰ってもらえるのではないか。作っているアプリも使ってくれるといいな。いう気持ちで書き始めました。意識するようなスライドにすべきだった次もこういうイベントに登壇していきたい登壇後、ブースにきて同じような悩みを持っていると教えてくれた方、発表後すぐによかったですよ。声をかけてくれた方など、聞いてくださった方々、本当にありがとうございました。SREネタもそのほか、決済系周りのネタもちょこちょこ溜まってきているのでどこかいいタイミングでまた登壇したいと思います。2020お昼は豊洲の「いちむら」というところでご飯を。刺身より肉料理の方が人気なのかも...ヨガ体験ちょっと早めについたので気になっていたヨガをやりました。座りながらでもできるヨガということで20分くらい。気持ちよかったですしよかったです。いう健康増進法みたいなのがテックカンファレンスには求められているのかも!基調講演speakerdeck.com「自動化の皮肉」というワードを知らなかったので勉強になりました。あとはエッジコンピューティングなど5Gが出てくるとエッジでよしなにできる環境が必要となってきそうなのでさらに分散コンピューティングの知識や考え方が必要だろうなぁと考えさせられる講演でした。仕事でもよく、DynamoDBをよく使っていて、個人的には結構好きなソリューションなのですが、やはり分散環境にしたおかげで出てくるRDBMSとは異なる特性などには悩んでいて難しいものだなぁと感じたところでした。絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長speakerdeck.comメルカリ、メルペイSREの組織の成長と取り組みについて。メルカリさんでは、SREをさらに細分化しているということで、最後のパネルディスカッションでもあったように、SWEの中の専門職で信頼性を担うものがSREなのであればさらにその領域の中で細分化されていくのはある程度大きな組織であると当然なのかもなぁ。大変だろうなぁと思うのはこういう凄腕エンジニアをまとめるEMの方はどうやったらそういう立場になれるのでしょうね...計画的に負荷リスクを排除するためのキャパシティプランニングspeakerdeck.comキャパシティプランニングを適切に行うために負荷環境をきちんとつくっている。ことで、自分も仕事で散々作りたいと思いつつ全然できていないことなので素直に素晴らしい取り組みだ。プランニングなどのビジネスサイドにわざと遅い環境で操作をしてもらい、どこから許容できないか、不快な環境というものを数値化してきちんとしたSLOを設定できているところも素晴らしいですし、真似したいと強く感じました。負荷環境その物を作るのが苦労しそうな気がするのですがそこら辺はどうやって作っているのか、もちょっと聞いてみたかったですね。Webサービスを1日10回デプロイするための取りくみspeakerdeck.comカヤックfujiwaraさん。いうのはどれくらいの頻度でするものなのか、というのを改めて数値化されていたことがよかったです。10回くらいデプロイできるんじゃね。軽く思っていたのが恥ずかしいくらいです💦やはり、テストが遅いということがイライラするというのはみんな共通ですね。CircleCIで殴るという。仕事でCodeBuildを使っているのですが、CircleCIのようなお気軽分散環境が提供されたらもっといいのになぁと恨めしく思いながら聞いていましたwまとめ上に書いた講演以外にも並行していろいろな講演があり、全部聞くことができなかったのであとで復習したいですね。久々にこういうイベントに行き刺激をもらえました。あったら行きたいと強く思えるイベントで最高でした。イベントを作ってくれた皆様、本当にありがとうございました!追記6gr.amいまちょうどこういうアプリケーションをつくっています。出る予定だと思います。発行できたり、複数人でグループを作ってそこで出資しあってお金を使う、みたいな今までにない面白い使い方ができるアプリです。実は中身もほぼすべて自分たちで実装しているので、日本国内のカードネットワークで流れの仕組みや、どういう応答をすればいいか、などなどいろんなことに詳しくなりました。今は還元施策とかはありませんが、将来的にはそういうのもあるかもですねwてなわけで興味のある方、ぜひ使ってみてください。IDが使えるようになってたのでその設定などライフハックこんにちは。5Cを買ってもらい、AWSやら何やらにセキュリティキーとして登録しまくっています。IDが使えるようになってました。いいますかこれが再現したのは以下の環境です。(64-bit)もしかすると環境によってまだしっかり動かない場合もあると思います。はじめに2段階認証を有効にするDropboxでは物理キーを登録するためには物理キー以外の2段階認証の設定をまずする必要があります。AuthenticatorやAuthyなどを使って登録します。開き、セキュリティキーの項目をクリックします。以下の画面のようになるので、「新しいキーを追加」をクリックします。続いて、特に何も考えずに、「設定を開始」します。キーは何も差し込んでいませんが、「キーが差し込まれました」をクリック。問題なく指紋が読み取られると、Chromeが許可して〜と言ってくるので許可してあげます。名付けておきましょう。ログインを試してみる2段階認証が有効になっているのであれば一度ログアウトして再度ログインすると2段階認証の入力が求められるはずです。IDに置くだけで2段階認証を突破できます。今までのようにAuthyなどでいちいち6桁の番号を読みとって入力する手間が省け超便利なのでおすすめです。IDを使える場所を見つけたのははじめてだったので驚いて記事にしてしまいました。使えるように実装が入っているようです。MeshというAWS上のマイクロサービスのアプリケーション間の通信を監視、制御できるサービスメッシュがパブリックプレビューとしてリリースされていましたので簡単に触ってみました。Meshでは、アプリケーションの可視化や通信制御などにはオープンソースで開発されていて、最近CNCFから卒業したEnvoyを利用しているようです。Meshを触ってみます。CLIをインストールしてきます。インストールしました。Meshを触るためにAWSの情報を設定します。Meshはus-west-2us-east-1us-east-2eu-west-1でのみサポートされているようなのでそのうちの一つのリージョンを選びましょう。私はオレゴンリージョンを選びました。次に、以下の環境変数を設定します。SERVICES_DOMAIN=default.svc.cluster.localこんな感じ。キーペアの部分だけはきちんと存在するやつを登録すればokかと思います。ここまでできたら次はVPCを作成します。今回はありがたい事にCloudformationによるテンプレートがすべて用意されていたためコマンド1発で完了します。Meshをセットアップします。create-mesh最後にECSクラスターを作成してみます。リポジトリには、ColorAppというアプリケーションが用意されています。用意されているため、ECRのリポジトリを作成しておき、イメージを作成しECRにプッシュしておきます。実行するとプッシュまでしてくれます。routerとrouteをセットアップします。./servicemesh/deploy.shつづいて先程用意した2つのアプリケーションをECSにデプロイします。./ecs/ecs-colorapp.shアプリへアクセスしてみる適当に1台踏み台インスタンスをECSクラスターのVPC上に作成しておきます。http://colorgateway.${SERVICES_DOMAIN}:9080/colorで動いている様子がわかります。とそれらの可視化を先に学んでくると良さそうですwもし、X-RayやCloudWatchで可視化できるようになったら続きを書くかもです。Cloudを利用しているサービスで大きな障害が発生していました。有名なサービスとしてはポケモンGoやSpotifyなどがサービス不可の状況になっていたようです。日本国内ではインシデント発生時刻が早朝のためあまり大きな障害はなかったようですが、米国時間ではちょうどお昼ごろのため大きな影響があったと推測されます。5時台に障害が発生した模様です。当該時刻にはその他のサービスもエラーを上げていたようで、珍しくステータスダッシュボードが燃えていました。Portal/APIが影響を受けていたようです。Balancingの障害によるものでした。CAUSEというセクションがあったため読んでみました。GFE)は2層の階層構造を持っているそうです。第1層目がユーザーからのリクエストを直接受けつけ、続いてサービスのデプロイされているリージョンか、アベイラビリティゾーンに存在する2層目のロードバランサーに振り分けられるような構成だそうです。この構成になっていることでエンドユーザーが世界のどこにいてもそのユーザーの一番近い第1層のGFEに接続に行き内部でルーティングされ第2層のGFEを経由してバックエンドサービスに繋がってレスポンスを返すとなっている。online.今回はGFEの開発チームが第2層のロードバランサーにセキュリティと性能の向上する機能を追加しているときに起きた。この機能はコードベースにはマージされていますがサービスインはしていなかったそうです。この機能の一部にGFEを再起動させるバグが混入されていましたが、テストや初期のデプロイでは検知できなかったとも書いてあります。実際にこの設定を本番環境に適用したところ、GFEが一気に再起動していき、ロードバランサーの容量不足になり処理ができなくなってしまった。いうのが今回のインシデントにつながった。テストを網羅しているつもりでもテストでカバーできていなかったところのバグが世界的な障害の起因となるというのは怖い話ですがあのGoogleでもやるときはやるんだなー(笑)とも思いました。まとめこういう前段の障害をどう回避するか結構難しい問題かな?と思います。やるとすると、GCP以外の他のクラウドにもサービスを投入しておいて障害が出次第、DNS等の設定でGCP側に振り分けないようにするくらいしか対応ができないかなーと思います。良さげな方法を知っている方がいたら教えてください。Publickeyにも情報が日本語で出てきました。みたいなことを質問されて、ラウンジとはなんぞやという話をしました。いうことに興味のある方の参考になれば幸いです。本記事内は基本的に国内線に限定して話をします。国際線の場合はちょっと異なることをご了承ください。すると正しくない情報があるかもしれません。その際はコメントください。待合室のひとつで、公共の休憩室やロビー、家庭内の居間や客間など、寛げるスペース。