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

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

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

夫婦喧嘩からはじまるCI/CD #

• 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 波田野 裕一さん #

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

CI/CDのデザインマップ

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

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

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

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

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

• 情報を取り入れるだけでなく、情報を交換するのがコミュニティ。
• 昔はEC2だっておもちゃだと思われていた。 RaspberryPiもそう。
  • やったことはだいたいLinux上で動く。

• "やってみた"は全量の2割くらい。
• "やってみた"で終わらせない。

• AI関連の案件が増えてきた。
• connectedな製品が増えてきた。

• ビジネス領域は、機能面でも、費用面でも増えてきている。
  • できることが、どんどん製品に取り込まれて増えてきた。
  • 開拓者に追随した人が新たに何かやる、というのが増えている。
• 世の中にないものをIoTで、という事例が増えている。

• やり方はさておき、必要性は感じる。人よりもIoT機器の数が膨大になり管理しきれず、攻撃の踏み台にされる心配がある。
• ハードウェアに出荷前の段階で、証明書を入れたりする作業は結構コストになる。
• 企業内の設備はセキュリティがゆるい。 ベンダー側からはお客様に啓蒙していかなくてはならない。
• 日本はICTへの施策は奥手だった。 世界の先陣きって実施する姿勢はよい。

• データ量を要求される。
  • 動画のストリーミングだったり。
  • 機械学習だと避けては通れない。
• センサー側のコード化。
  • ただデータを送るのではなく、画像ならフレームの差分だけ抽出して、できるだけデータ通信量を抑える。

• IoTでビジネスをしたいのであれば、クラウドは手段なので言ってしまえばどこでもいい。
• Greenglassなどのサービスを先陣きってやってくるのがよい。

IoTとエコシステム #

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

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

[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.
  • 出力結果から特定のノードを取り出すことができる。

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