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.
- 出力結果から特定のノードを取り出すことができる。
運営スタッフの皆様、登壇者の皆様、スポンサーの皆様
本当にありがとうございました。