AWS re:Invent 2日目 ~DevOps系セッションの紹介~

AWS, re:Invent, re:Invent2017

この記事は最終更新日から1年以上が経過しています。

セッション紹介

今日は DevOps 周りのセッションを2つ回りました。

昨日色々試したお陰で、スライド撮影のノウハウがたまってきました。
コツは2つで

  • 前から10番目以内に座らないと綺麗に写すことはムリ。撮影したいセッションは早めに並ぶ。1時間くらいは並ぶ。
  • スライド撮影に強いアプリは iOS の Microsoft Pix(文字を認識してくっきり写るように補正をかけてくれる)
    • 逆に、Xperia はデフォルトだと露出が高くてスライドの撮影には向かない

おかげで、今日は後で見返した時に何て書いてあるか分かるレベルのスライドの写真が撮れました。

DEV345 – Tools Won’t Fix Your Broken DevOps

かなり面白いセッションでした。
DevOps Research and Assessment LLC の Jez Humble 氏 と Nicole Forsgren 氏 による軽快な話し口調による笑いが絶えないセッションでした。(軽快すぎて「もっとゆっくり喋ってくれ！」と何度か思いましたが)
Research系の方ということで、大量の引用の元で結論へと進んでいく話の組み立て方が研究発表みたいで、数年前を思い出しました。
現場の開発体制は Water – Scrum – Fall モデル(アジャイル開発と言いながら、実はそれっぽい型を使っているだけのウォーターフォールモデル)だと言う話から始まり、DevOpsが本当の意味で成功しているというのはどういう時なのかを説明するセッションでした。

いくつかある構成要素の中で特に時間を割いて説明していたのが “Culture” についてで、
そもそも、ソフトウェア開発のパフォーマンスを定量的にはかるにはどうすれば良いか、という定義を行い、

結果、どのような仕事をしている人がパフォーマンスが高いかや

良いチームとはどのようなチームであるか(オリジナルはこちら)についてのデータを示しました。

多くの人が共感していたのがこのスライドで、一言で言うと「CTOでもインターンシップの学生でも、イノベーションは等しく起こせる」という話です。(イノベーションとカタカナで書くとちょっと大仰な事のような気がしますが、英語でのニュアンスはもう少し小規模なものです)

結論としては、「みんな、DevOpsは出来るよ！」という話と「もっと詳しいデータは私たちのWebサイトで無料で見れるよ」という宣伝で終わりでした。

資料中に出た細かいデータの詳細についてはNicole Forsgren 氏が口頭で説明していた(というか、このセッションのほとんどが口頭説明でした)のですが、ちゃんと聞き取れているかがかなり怪しいので「後日公開される動画をご確認ください！」という形でお茶を濁しておきます…

DEV315 – GitHub to AWS Lambda: Developing, Testing, and Deploying Serverless Apps

「画像をアップロードすると、それを自動でリサイズするLambda」のDevOps環境を構築する方法を3パターン紹介するというセッションでした。
DevOps とは大まかに言うと以下の流れになります

  • リポジトリにソースをPUSHする
  • 自動で単体・結合テストが走る
  • コードのレビューして、OKならばMergeする
  • Merge されたら、自動的にビルド・デプロイされる

これを、以下の3つの方法で実際に構築する手順を紹介しました。


↑ GitHub + CodePipeline + CloudFormation の時の構成図

手順といっても、必要な部分だけ抜粋なのではなく、本当にユーザやロールの作成の部分から全部説明する、そのままハンズオンにできそうな内容でした。
45分のセッションだったのですが、スクリーンショット(おそらく100枚を超えている)を次々とめくっていく形式で、スライドを全て撮影しようと試みていた人は途中で動画撮影に切り替えていました。

最初の Jenkins では相当な手順があったものが、CodePipeline + CodeBuild を使う方法になると半分くらいになり、CodeStar を使うと手順が更に減りました。

こういった、手順紹介系あるあるだと思うのですが、思わぬ所で便利コマンドを知りました。
リポジトリ設定の中で、Branch –> リポジトリのEdit –> Require status checks to pass before merging にチェックを入れると、「テストを通るまでマージができない」という制限をGithub上で行うことが出来ます。
私の関わっているシステムの場合は自動テストが何時間もかかるので、これを行うと開発スピードが落ちそうなのですが、マージされたブランチの品質を一定に保つという意味で、(テストがもっと早く終わる仕組み作りができたら)組み込んでおきたいです。

CodePipeline や CodeBuild は正直「面倒そう…」と思って避けていたのですが、CodeStar を使うと手間はかなり減るように思えました。
既存の枠組みがあるのであれば、乗り換える程の大きなメリットはちょっと厳しいですが、今から Jenkins で構築を行うのであれば CodeStar を使った方が同じ事が楽にできそうです。

おわりに

3日目になると少し疲れが出てきましたが、明日はいよいよ基調講演です。エンジニアは基本的に朝に弱いイメージなのですが、なぜか 8:00AM から基調講演がスタートします。
個人的には DevOps 系か Container 系の新サービスが発表されるといいなぁと思いながら、頑張って起きます。

AWS, re:Invent, re:Invent2017