JAWS DAYS 2019 に行ってきました.

下記は、自分が聴講したセッションのメモとスライドのリンクです.

[アーキテクチャ]今日からはじめるCI/CD…のためのAWSアーキテクチャ事始め

夫婦喧嘩からはじまるCI/CD by 山﨑 奈緒美さん

• webサーバ2台のサービス規模だとしても、それさえ手動で構築は面倒.
  -> CI/CDを導入してはどうか、という会話になった.
• 今後サーバ台数を増やしたいときも手動? それはどうなの?
• 導入するメリットは?
  • 手動ではなく AutoScalling.
  • update や bugfix を、手動の上書きではなく Immutable に運用したい.
  • 将来サービスをインスタンス化、マイクロサービス化したいなら、なおさら導入するべき.

CI/CD と AutoScalling は違う.
まずは CI/CD を分けて考える.

CI(Continous Integration)

• 開発の本質
  • bug の早期発見および対処.
  • software の品質向上.

CD(Continuous Delivery/Deployment)

• Delivery
  • 承認がないと本番にデプロイできないことがある.
• Deployment
  • 継続的に行えること.
  • deploy に無駄な時間をかけずに迅速に対応できること.

システムの品質向上が目的

• 何のためのシステム?
  etc. カスタマー向け、企業ユーザ向け、社内向け

リソースの属人化や権限の縦割りって無駄.

• 開発者自身が自由にリリースできる方が良い.
• リリース権限者がボトルネックになる可能性.
• リリース権限の縦割り、が古い考え方.

CD からはじめるほうがお手軽

• CI/CD を一気に導入するのは考えることが多くてたいへん.
• 既存プロジェクトに後から CI 導入は難しい.
• CI やるにはテストコードが必要なので、CD (deploy) だけでも自動化してみる.
• 非コンパイル言語なら CD だけでもやって見る価値あり.
• リリース頻度が週1,2回以上ならなおさらやるべき.

今日からはじめるCI/CD by 波田野 裕一さん

  <div class="twitter-embed">        <blockquote class="twitter-tweet"><a href="https://twitter.com/tcsh/status/1099158043730702336"></a></blockquote>        <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>      </div>      

"サービスに自分たちを合わせるのではなく、自分たちのパイプラインにサービスを組み込む" by SA 大村さん

CI/CD のデザインマップ

• 自分たちのパイプラインの行き先はユーザ.
• ツールに精通しても時代が変われば意味がない.
• パイプラインの行き先がユーザになっていれば、使用されているツールはなんでもよい.

[ハイブリッドクラウド] クラウドからオンプレを管理する！ AWS の Management Tools を使ったハイブリッドアーキテクチャ
by 大村 幸敬さん

  <div class="twitter-embed">        <blockquote class="twitter-tweet"><a href="https://twitter.com/yktko/status/1099172529300590593"></a></blockquote>        <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>      </div>      

[IoT]IoT野郎が語り合う、IoTの今と未来、そしてエコシステム

こちらはTwitter(#iot野郎)でお題を募集するパネルディスカッション形式でした.

コミュニティとエコシステム

• 情報を取り入れるだけでなく、情報を交換するのがコミュニティ.

• 昔はEC2だっておもちゃだと思われていた. RaspberryPiもそう.

  • やったことはだいたいLinux上で動く.

• "やってみた"は全量の2割くらい.

• "やってみた"で終わらせない.

  <div class="twitter-embed">        <blockquote class="twitter-tweet"><a href="https://twitter.com/TomookaKenji/status/1099164202726354944"></a></blockquote>        <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>      </div>      
  

• AI関連の案件が増えてきた.

• connected な製品が増えてきた.

  <div class="twitter-embed">        <blockquote class="twitter-tweet"><a href="https://twitter.com/lumin/status/1099165027985059845"></a></blockquote>        <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>      </div>      
  

• ビジネス領域は、機能面でも、費用面でも増えてきている.

  • できることが、どんどん製品に取り込まれて増えてきた.
  • 開拓者に追随した人が新たに何かやる、というのが増えている.

• 世の中にないものをIoTで、という事例が増えている.

  <div class="twitter-embed">        <blockquote class="twitter-tweet"><a href="https://twitter.com/smogami/status/1099166128511713280"></a></blockquote>        <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>      </div>      
  

• やり方はさておき、必要性は感じる。人よりもIoT機器の数が膨大になり管理しきれず、攻撃の踏み台にされる心配がある.

• ハードウェアに出荷前の段階で、証明書を入れたりする作業は結構コストになる.

• 企業内の設備はセキュリティがゆるい. ベンダー側からはお客様に啓蒙していかなくてはならない.

• 日本はICTへの施策は奥手だった. 世界の先陣きって実施する姿勢はよい.

  <div class="twitter-embed">        <blockquote class="twitter-tweet"><a href="https://twitter.com/tomokyun85/status/1099166302533369856"></a></blockquote>        <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>      </div>      
  

• データ量を要求される.

  • 動画のストリーミングだったり.
  • 機械学習だと避けては通れない.

• センサー側のコード化.

  • ただデータを送るのではなく、画像ならフレームの差分だけ抽出して、できるだけデータ通信量を抑える.

• IoTでビジネスをしたいのであれば、クラウドは手段なので言ってしまえばどこでもいい.

• Greenglass などのサービスを先陣きってやってくるのがよい.

IoTとエコシステム

• お客様は、導入までの手数を減らしたいはず.
  • IoTセレクション. ソリューションをそのまま借りることができる.

[Others]Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する

  <div class="speakerdeck-slide">        <script async class="speakerdeck-embed"          data-slide="1"          data-id="a034beb9ba2b4485856f9bbe365a7487"          data-ratio="1.77777777777778"          src="//speakerdeck.com/assets/embed.js">        </script>      </div>

[CLI]AWS CLIではじめるコマンドラインライフ 〜 正しい「運用自動化」への第一歩 by 波田野 裕一さん

"GUI は中学生まで"
"運用自動化" よりも "運用構造化" の未来へ

GUI

• なんとなく理解していれば、つつがなく作業完了(ほんとに?).
• なにか起きたときに対応できる知見がつかない.
• GUI 手順作成は、CUI の3倍の手間、1/3の品質.
• UI 改訂のあおりを受ける.

CUI

• コマンドや API など低レベルで機能を理解して作業.
• 一歩ずつ確実に知見を積み上げることができる.

AWS サービスは API の集合体

• AWSは全ての機能をAPIで提供している.
• "AWSを真に理解する"とは"AWS APIの仕様を理解する"こと.

AWS CLI のバージョンは週4~5回更新.

• GUI でできないけど CLI ならできることが4000以上.
• 後回しにすればするほど学習コストが高くなる.
• 変更差異が確実にわかるので undo ができる.
• ちなみに CloudFormation で対応しているサービスは、全サービスの半分以下.

AWS CLI利用方法

• 何はともあれ公式リファレンス.
• 補完機能
• 強力なJAMESPath.
  • 出力結果から特定のノードを取り出すことができる.

運営スタッフの皆様、登壇者の皆様、スポンサーの皆様
本当にありがとうございました。