tec_tec_blog

いちSEの日々の興味のあるところを取止めなく

JJUG CCC 2017 Fallに参加してきました

JJUG CCC 2017 Fallに参加してきました。

家族イベントがあったので、午後からの参加です。

 

1コマ目

www.slideshare.net

安定のカサレアル多田さんのセッション。教えるプロということもあり

説明がわかりやすい!Springは使う一方で内部構造全く理解していなかったので

内部ソースを追うきっかけをいただいたセッションでした!

以下がセッション内メモ。

  • SpringMVCはDispatchServletで全リクエストを受付、この中にコンテナを持っている
  • ViewResolverインターフェースで、テンプレートエンジンの切り替えなどw実装できる。
  • SpringMVCは拡張、差し替えしやすいように徹底的にインターフェース化されている。バリデータ、コンバータ、URLとコントーラメソッドの紐付け
  • 過去はたくさんの@Beanで定義が必要であったが、@EnableMvcだけでよくなった。 中身は@Import
  • @Controllerの中身は@Component.
  • SpringBootは何を自動化するのか? コンテナはフレームワークを動かすBeanと、業務で使いたいBeanに別れる 業務側は、コントローラとビジネスロジックリポジトリ、ぐらい。
  • >SpringBootが行うことはフレームワークを動かすBeanを定義済み ⇨大量のJavaConfigの塊
  • セットアップ最小限ですぐ開発できる。アプリを構成するBeanにはノータッチ
  • application.propertiesで記述した設定はAutoConfigurationクラスに渡されて使われる
  • spring.factoriesを読み込み、記載されている次に読み込むAutoConfigurationの読み込みを行う
  • spring-boot-autoconfigure.jarには、ほぼ全てのBeanが定義されている。 Springイニシャライザーで複数コンポーネントを選定するが、上記設定ファイルにはほぼ全て最初から書かれている ⇨選定が行われる。条件は@ConditionalOnXX ⇨クラスパス上にthymeleafのライブラリがあれば、Beanを有効化するなどの 実装がかかれている
  • EnableXXをつけない、自前でBean定義しないのが安全 安全なカスタマイズ方法:補助的なBeanを定義して、コンテナから拾ってもらう Bootで準備されている、XxxCoustmizerを使う

 2コマ目

qiita.com事前に調べてから行けばよかったのだが、過去に別の勉強会で話して、

QiitaにUp済みの内容でした。既視感がすごかったです。

ただし、デモや説明として聞けたことが大きかったです。

  • SecurityはServlet のFilter機能を利用してセキュリティ機能を提供するフレームワーク
  • セッションIDの盗用はクエリパラメータにセットする、など。
  • SpringSecurityはURLリライティングを検知して、消す処理がデフォルトで備わっている
  • ログインの前後でセッションIDを変化させないとダメ
  • SpringSecrityはFormログインしたときにはデフォルトでセッションIDをかえてくれる
  • CSRFリクエストが正規のページからきたことを確実に判断することが大事。
    トークン発行など。
  • SpringSecurityではデフォルト有効
  • クリックジャッキング、みえないiframeをボタンの上に乗っけて正規のページの処理を動かされている

3コマ目

Oracle伊藤さんのJDKリリースモデル説明

資料はアップしないとのこと。Oracle正式見解として、Web上にページ公開を

社内で計画しているから、、とのことです。

  • JavaーCadence:リリースモデルを変える話
  • JDK9は過去最大の機能追加数:91?
  • JavaSEのリリースまでには2つの関門が。
    OpenJDKー>JCPの投票
  • 新しいリリースモデル11/17現在
    6ヶ月で定期リリース、削除提案、削除実行のプロセスも含まれる
  • OpenJDKもバイナリでもリリースする。v9.0.1が最新
  • 1年後のリリースまでにOpenJDKを機能強化させ、OracleJDKと同機能まで持っている.フライトコントローラ、ミッションコントローラ
  • Z garbage Collector:オラクルのインターナルプロジェクト、マルチテラバイトGC、10msec以下
    Application Class Data Sharing,
    Ahead of Time Comlilation:出せるのかが不安になってきている。引っ込める可能性もある
  • コミュ二ティとの連携は継続、OpenJDK,JCP
  • OracleJDKはLTS版のみのリリースとなる。11LTSの次は17LTSとなる
  • 半年毎のリリースはOpenJDKのみ。
  • リリース情報の提供はOpenJDKにのっているものが最新。Featuresの欄が新機能情報。
    http://openjdk.java.net/projects/jdk/10/
  • リリースドキュメントも重要。Deprecatedの運用ルールはそのまま
    ⇨最短1年(Deprecated:削除タグがついて2バージョン後)で機能が削除される可能性あり。
  • CORBA関連の機能がなくなることがJavaOne内で言及があった
  • Oracle公式アップデートの終了
  • JDK8:2018年9月,9,10は半年。
  • 8の移行先は11移行推奨。9,10は機能評価用として利用すべきもの。
  • Java8のDeployment Techonologyは通常のJava8より短い。Applet,JWTなど。
  • OpenJDKでもLTSという話がでてきた。(DevoxxでMarkRainfoldが言及)
  • IEはJavaSE9の64bit版を認識しない。
  • *JavaSE9以降は自動更新は行われない。
  • *JavaSE9の32bit版のバイナリ提供の予定は現状なし。

 4コマ目

pring BootとKafkaでCQRSなアプリを動かしてみる
#ccc_e6
楽天椎葉さん

 

ツイッター上でやり取りさせていただきました!レスポンスあって嬉しい!

物腰柔らかくて良い人でしたー。

 

  • CQRSはGreg Youngが名つけたもの。
  • コマンドとクエリを別のオブジェクトに分ける。
    (プレゼンの図はCacooで書くとかきやすい)
  • 複雑なものをキープしたい、複雑なものをどうやって改善するか。。
  • DDD:ソフトウェアの複雑さの核心にせまる
  • DDDの印象:依存関係を切り離し、凝縮させて複雑さを回避していく
  • DBからの解放はステキ。だけどUIからの解放は難しかった。集約とか、集約からの導出した値で検索やソートをしたり。。
    -> JOINを使い、妥協した
  • ドメインモデルは更新側が重要。クエリ側はDAOにしてしまう、といったアイデアもでてくる
  • ステートソーシング:現状の状態を連携、管理する。ビール残り3本、残り1本、など
  • イベントソーシング:起こった出来事を管理、連携する。ビール3本買って来た。1本飲んだ。など:過去の履歴が追いやすい
  • CQRSとするなら、
    更新側ではイベントソースに投入するのみ。そこからDBに非同期で反映。
  • CQRSはEvent SourcingへのStepping-Stone(踏み台)
  • CQRS/Event sourcingを全体に適応しない。コストが高く、難しい。必要なところに集中してやるのが良い
  • Kafka 分散ストリーミングプラットフォーム
  • MQの場合はキューにはいったものが読みこまれると消えてしまうが
    Kafkaは読み取っても消えないし、過去の分も読み込める

最後のコマ

Serverspec NTTDataのサーバスペック活用のお話

  • アプリの自動化は進んでいたが、インフラ自動化はなかなか浸透してこなかった。
  • 商用ミドルウェア単体テスト自動化 #jjug_ccc #ccc_a8
  • これまでは
  • パラメータシート>構築手順書・テスト項目書>構築対象
  • を全て手動で転記や対応。
  • 案件での実績としては110ノードの単体テストを作業ミスなしで3週間の遅れをとりもどす!
  • パラメータシートのフォーマットがミドルウェア、チームごとにバラバラ
  • WebLogicだけでも2800以上あった。自動化スクリプトが肥大化&未管理
  • ・パラメータシートのフォーマットを統一化
  • ・そのシートを元に自動生成の定義(自動)と、テストスクリプト(手動?)を生成
  • WLSTが内包されていて、便利なので活用する方針
  • テストスクリプトをテンプレート化し、変数群をyamlに転記するよう自動化。
  • 状態確認ができるものはそれをやる。できない場合はデプロイ後の設定ファイルを確認する。
  • ⇨テストパターンによりテストロジックを共通化する
  • フォーマットやツールについては現状公開予定はないが、他社さんとかで公開している事例があるので
    参考にした方が良い。
  • 1Nodeで複数ミドルウェアをいれてるとインストールする中で勝手に変更するケースもあり、
    考慮が必要。(順序性とか?)
  • QAタイムでパラメータシートExcelとか、転記マクロとか公開してくれませんか?とお願いしたが、現状予定なしとのこと。世の中にもいくつかあるようだとのコメントいただいたので、時間あるとき探したいと思いましたー。

懇親会は家族とのご飯予定があったので、帰りました。寒い日でしたが

イベントはアツかったですね!

 

運営とスピーカーにいつも感謝。

おつかれさまでしたー。

 

 

Set.ofの実態とは?

Java9から、Set.of関数などデフォルトメソッドがインターフェースに

実装されたので、簡単にSetのオブジェクトが作成できるようになった。

 

実体として何のクラスのオブジェクトが作られるのか気になったので

やってみた。

 

$ ./jshell
| JShellへようこそ -- バージョン9
| 概要については、次を入力してください: /help intro

jshell> Set.of("a","b")
$1 ==> [b, a]

jshell> $1.getClass()
$2 ==> class java.util.ImmutableCollections$Set2

 

ということで、java.util.ImmutableCollections

が実クラスでした。イミュータブルなものとして使えるというフレコミだったので、そのままでした。

SpringBootハンズオン#2 に参加してきました

2017年7月26日にYahoo!ショッピング主催のSpringBootハンズオンに参加しました。

SpringとPCFがハンズオン形式で学べるとのことなので、

楽しみにして参加してきました。

 

connpass.com

事前にそこそこ触ってから行き、資料がかなりシンプルに分かり易く作られていたので

集中して、サクッと経験を積むことができたのが有難かったです。

 

やったことは以下です。

  • SpringBootアプリの単体テスト
  • SpringBootアプリのDBテスト(Junitで実行できる形)
  • SpringBootアプリのEtoEテスト(Junitで実行できる形)
  • PCFの起動、デプロイ
  • PCFでのスケール(スケールアウト、スケールアップ)
  • PCFでのブルーグリーンデプロイメント

 

動かしてみて初めてわかったのですが、SpringBoot系の推奨テストは

Junitベース。コンソールを見てると都度都度SpringBootを起動しているログが出ていた。

テストケースが多いと、時間がかかりそう。。そうなったらグループ分けなどして複数プロセスとかで並行テストとかを考える必要がありそうと感じた。

 

Yahoo!ショッピングさん、貴重な機会ありがとうございました!!!

 

JustTechTalk#09に参加してきました

2017年06月30日にありました、
JustTechTalk#09 Webサービスを支える「インフラ」の運用事例とベストプラクティス
に参加してきました。

※資料は公開され次第、リンクを追記します

最近、AWSを活用するケースが多いと思うのですが、やり方が多く、

どうするのが良いのか迷う場面が多くなりましたので、その一助になれば良いかと思い、参加です。

 

justsystems.doorkeeper.jp

特に、案内の中にもあった、

運用テーマ
AWSセキュリティ要件を考慮した最適構成
AWS構築/デプロイの自動化
AWSコストダウンと自動バックアップ
・早期発見/復旧でAWSシステム安定運用

運用ツール
・Ansible/Packer/Terraform/Fluentd
・GitLab/Jenkins
AWS CodeDeploy/
AWS CloudTrail/ColudWatch/EC2 Systems Manager
AWS Athena
・Zabbix

あたりの話を聞きたかったのです。

JustTechTalkへの参加は初めてでしたが、参加者の年齢層は結構バラバラ

若い人たちばかり、、といった感じではなかったです。

その分、地に足ついた内容といった印象を受けました。

 

①DevOpsをどのように進めたか
元々は開発部門と基盤・インフラ部門が分かれていた
→組織改編があり、詳細設計・開発構築時には同じ組織になった。
ただし、そうなると、インフラ担当がアプリケーションの中を理解する必要がある。
開発部門も同様に、インフラのことを知らなければいけない。
→結局組織は一つだが、なんとなく担当は別れるので、結局、仲を取り持つ、

両方(インフラとアプリ)を知っている人が重要。

チーム一体化のデメリット
→管理者、評価者が管理、理解する範囲は増え負担が増える

AWS管理のポイント:AWSアカウントは単一だと危険。
カオスになってくる。(セキュリティグループ、IAM、ACL,,,)
作業ミスで破壊される可能性。

 

terraformでAWSの構成を作成。
→terraformは状態ファイルを持つため。手作業で基盤を変えた場合は差分が発生するため注意
Ansibleなどツール自体の不具合に注意。まだまだある。Bug情報をwatchする必要あり。(これは何にしても、、ですが、)

ユースケース、パラメータ的網羅テストもアプリケーション同様に考え、テストを実施する

今後はログの調査、分析の簡易化、仕組み化を便利にするように推進中。
Amazon CloudwatchLogis,Kibana,を利用。
現状はzabbixを使っていて問題は発生していないが、ノウハウをもっている人に依存してしまっているという課題を認識しており、makalel等に移行するかを検討中。

 

AWS運用における最適パターン
「サービスの責任はアプリケーション開発者が持つ」
梵字徹底:当たり前のことを確実にやる
AWSのベストプラクティスを参考に、実践例も交えて検討する。
コードで確実に、同じ結果にすることが大切

AWS構築、デプロイの自動化
JenkinsからGitLab-CIに。Dockerベースなので良い。(自分にはその良さがわかりませんでしたが)
導入コストが低く、保守も簡単。たまにバグを踏むとのこと。。

 

③ログ管理のベストプラクティス

AWS桑野さん(前職はCA)

CloudWatchLogs,CloudTrail:APIを操作を記録するサービス。
管理コンソール、APIなどが対象。誰がいつAPIを発行したのか、されたのか。

リアルタイム処理が不要であれば、バッチ処理
必要であれば、Streamで処理。
ログ収集サーバに集めるとそこがSPOFになるしスケールしづらい。そこでミドルウェアアプリケーションの利用:Fluentd, Logstatsh, Flume。
バッファリングしてくれるFluentd(OSS)が便利。
Fluentdを多段で組むのが基本スタイルとなる。Aggregation Serverを中間に立てるイメージ。

Kinesis FirehouseでFluentd→S3の連携をEC2無しに実現。
今年のAWS Summitで後2ヶ月ぐらいで東京リージョンに来ると発表されていたので、もうすぐ使えるようになるはず。
直接送れば Aggregation Server不要でシンプルな構成に。Aggregation Serverのスケールアウトも気にしなくていい。

ただしKinesisからログを取得するにはLambdaかEC2が必要→そこで Kinesis Firehose!

Fluentdから直接S3に送ると変更するのが大変、特に書けなかったときのリトライ処理が面倒。


全てのログをS3に貯め続けることが大切。データレイク化の発想。
Amazon athena:S3においたデータに直接SQL実行可能
tokyoでも最近から利用可能になった。
スキャンしたしたデータ1TBあたり5ドルだが、一度スキャンしたものをまたS3に入れて

それを見たり、それからRedShiftで活用したりと節約ポイントはある模様。

 

まとめ

現場でどうやっているか、何に困ってどう対策したかなどが、かなり勉強になりました。開催ありがとうございました。

 

MEANスタックのExpressについて調べたまとめ

ちょっとしたきっかけで、調べた個人メモ。


Node.js:サーバサイドJavascriptの実行環境。
ExpressはそのNode.jsでのフレームワーク

REST APIも簡単に作ることができる。JSONを扱いやすい(JavaScriptとの相性が良い)
app.jsの記載例

const app = express()

// GETリクエストに対処
app.get([url], (request, response) => {
  // requestをもとに処理をし、クライアントにresponseを返す
})

// POSTリクエストに対処
app.post([url], (request, response) => {
  //
})

// PUTリクエストに対処
app.put([url], (request, response) => {
  //
})


// DELETEリクエストに対処
app.delete([url], (request, response) => {
  //
})

// ポートを指定してアクセスを受け付ける
app.listen([ポート番号], callback)


nodeを使うため、npmを活用でき、様々なツールも利用できる。

ExpressではテンプレートエンジンをJadeやEJSといったモジュールから選択することができる。

今回はHTMLがそのまま利用できるEJSが良い。EJSもNPMパッケージとして提供されている。npm installコマンドでインストール。

日本語サイト(公式)
http://expressjs.com/ja

英語サイト resourcesなどで日本語版との差分が顕著
http://expressjs.com/en/resources/middleware.html

Qiita:ゼロからはじめるExpress + Node.jsを使ったアプリ開発
http://qiita.com/nkjm/items/723990c518acfee6e473

Node.js+express+MongoDB+Mongooseで簡単なjsonサーバを構築するメモ
http://qiita.com/tdomen/items/4ecb15f25bf9c3652f59#_reference-403ebec67691a94893a1

DBアクセス

node.js から MongoDB にアクセス (Mongoose の紹介)
http://krdlab.hatenablog.com/entry/20110317/1300367785

node.js から MongoDB にアクセスためのライブラリに Mongoose がある
O/R Mapper っぽく使えるように設計されており,既存の O/R Mapper を使ったことがある人にとっては,比較的わかりやすい仕様.

 


Node.js + Express 4.x + MongoDB(Mongoose)でRESTfulなjsonAPIサーバの作成を丁寧に解説する.+ テストクライアントを用いたAPIテストまで
http://qiita.com/shopetan/items/58a62a366aac4f5faa20

レイテンシをあげたい場合は、、、Socket.IOを使う
Node.js、Socket.IO、MongoDBでリアルタイムWeb
http://www.atmarkit.co.jp/ait/articles/1210/10/news115.html

APIのテストをするには、、(内容古い?今はもっと良いものあるかも)
Postman - Google Chromeを使ったWeb APIテストクライアント
http://www.moongift.jp/2014/05/postman-google-chrome%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9Fweb-api%E3%83%86%E3%82%B9%E3%83%88%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88/

React+Redux+Express+MongoDBでものすごくシンプルなCRUDアプリをつくる
http://qiita.com/hoture/items/573247b12ff0bc4e5d3c#%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E5%81%B4

MEANのホームもあった。
http://mean.io/

 

リアクティブ入門

勉強中。このスライドがわかりやすい。

 

www.slideshare.net

Springはあまり知らないけれども、前半部分の触りだけでも、すごくまとまっている。

JAWS Days2017に参加してきました。かなり勉強になりました。

AWS Days2017 3.11 @TOC五反田メッセ のメモ。

初めてのJAWS Days参加でどんな雰囲気なのか心配でしたが、

エンジニアの集まり、お祭りな感じでとても楽しく、沢山の得たことあったなぁ。と

充実した1日でした。

 

参加したセッションを中心に。

 

- サーバレスアーキテクチャ

資料

 

www.slideshare.netLambdaの場合、処理がぬけた部分を考慮する必要がある
特有の課題を回避する必要あり。タイムアウト、リトライ実装必須。

EC2でも良いなら、そちらが安定。

DBの必要性を確認。S3で問題ない場合も多数。
LambdaとEC2の違い。
RestfulなAPIができれば良い話ではない。

  • Lambda:1対1


Lambdaには、運用でカバーで甘えられない現実がある
サーバレス開発は運用メンバーがフォローしてくれない。全て開発者に不具合が返ってくる。
実行されないことも含めてモニタリングが必要。
 →これまでインフラ部隊がやってくれた
非機能要件を開発者が実装する必要がある。守るところを守れるようにする。

運用時に不具合が発覚した場合もリカバリー処理を考慮した設計が必要で
開発時のコストが上がる現実。(運用費用は下がる)
TCOでの比較で決めていくべき。

MBS動画イズム444の事例→3ヶ月でリリース
cloud front + S3で大量アクセス不可への耐性の確保した。
dbを使わず、S3だけ。
月々のインフラコストを削減するためにサーバレスアーキテクチャを採用
フロントでできる処理はなるだけフロントで対応。(非会員はこれで十分)
→Lambdaをできるだけ使わない設計としている
処理時間が長いものはworkerを使って分散。
kintone(CMSとしても利用。セキュリティアクセス管理はお任せ)のサービスを利用しているが、APIの利用制限があるのでなるべくまとめてAPIをコールする。
世界三箇所から相互にモニタリングする仕組みを作っている。
監視間隔は5分。
モニタリングしているシステム同士も監視し合っている(3すくみ状態)。
lambdaベースで監視システムも作っているのでインフラコストを下げている(無料枠に十分収まる)
不正アクセスによるLambdaの実行回数制限を狙った攻撃への防御対応が必要だった。(APIのURLを知ると、攻撃可能)
1分間隔で不正を検知し不正IPをブロック。


- Fintech 最前線 渥美さん


立ち見も出るほどの盛況ぶり。200人ぐらい。
メガバンクも利用。日経からの3つの記事がでた。自身も勉強会で訪問した。
新規案件のうち50%、既存システムは更改時にクラウド化。→クラウドファースト
グループ共通の共通基盤とする。
3システムが稼働中。
10件弱開発中。20件検討中。
2017年中にAWSの資格習得者を30人育成
FIN TECH
リーマンショック、エンジニアが流出
格差拡大、Unbank、金融機関への不信
新テクノロジーとスタートアップが始まり
会議ではこの2−3年で投資が急激に拡大
海外では、既に金融機関を脅かしている
金融庁の危機感。→ワーキンググループを組成。
銀行のビジネスモデル→ソフトウェア産業化、APIエコシステム化
FISC安全対策基準第8版で(2015/08)リリース
金融機関におけるクラウド利用が示された
「現地サーバ視察は不要」
立入監査が実行的でない場合などは、第三者関西による代替も可能。
金融庁によるFINTECHアクションプランが(仮想通貨をいつまでに検討する、など)公開されている。
キーワードがイノベーション。ブロックチェーンなどの記載もあり。
FINTECHは登録制とする。ただし、スピード感は大切にする。(きぞんよりもゆるい、安全対策基準を設ける)
OpenAPIによる変化
今:電子決済等代行業者にID/PWを提供して、スクレイピングで銀行へアクセス(米国では主要だが、欧米では慎重)
OpenAPI:Fintech企業による代行。OAuth2.0でトークンでやりとりする。
一般社団法人FinTech協会の動きが活発になってきている


- コンテナに挫折したあなたへ
JAWSUGコンテナ支部 原さん
資料

speakerdeck.comコンテナとVMの違い
VMは配る際もOSも必要なので、稼働から、OS設定などが必要。電源を入れる的な作業が必要。
コンテナはDockerのデーモンプロセスが間に入るだけ。OSはない。
AWSの場合は、ゲストOSとしてEC2を使って、そのOS上でDockerを動かして、
その上でコンテナが動く。
Dockerコンテナ上のプロセス出会ってもホストOSの上でもpsで見える。
ただし、Linuxコンテナの技術を使って、違いに干渉しないように見えるので
プロセスIDの表示が異なる。コンテナの中からは自分のコンテナの中しか見えない
SI企業への発注の場合、ソースコードと、Dockerファイルをあわせて納品させると
UATで動かない、といったことがない。
コンテナはモダンなアプリケーション開発のベストプラクティスに沿ってない。
12-Factor app:Herokuが元になっている良いアプリケーションのベストプラクティス(2012-2012から変わっていない。その当時はDockerはない)
awsのwebinerでAWSにおける12-FactorAppについて50分説明しているものがあり。
コンテナに適した

  • チーム体制とデリバリー
  • アプリケーション(これが一番大事。ログを適切に吐くとか。IPが固定されていることが前提の作りとか。ディレクトリにここにファイルがあること前提とかにしない)
  • 運用(管理タスクもコンテナに)
  • インフラ構築

を明確にし、何がかけているのかをはっきりさせる
コンテナ登場以前のデリバリーソースコードコミットをトリガーにCIサーバがフックしてシェルべったりで実行環境にデプロイ

一方、コンテナ時代はCIサーバが直接デプロイではなく、Docker Registryに上げるところまで。
クラウド常にコンテナ管理ツール+事項環境となりうる。


実行定義に、イメージ、CPUメモリ、アプリ設定値、マウントするディレクトリ、公開するポート、コンテナ内で走らせるコマンドなど
を定義することで、どこの環境でも動くようにする。
世の中のコンテナ管理ツールは、非同期的な動きになっている。
クラスタ:複数のソースを1つのインスタンスとしてみなす。
リソースの有効活用。どこでも動かせる、いつでも復旧できる、に繋がる。
クラスタ時代はCPU利用率で見るのではなく、CPU予約率でメトリクスをみてスケールを判断する。
予約率が厳しくなってきたら、クラスタに追加した形でリソース追加
オススメは1プロジェクトで1クラスタ。例外があるとすると、バッチ処理だけ別にする。(時間が読みやすいので)

- AWSでアプリ開発するなら 知っておくべこと

 

www.slideshare.net参加したかったけど、時間に間に合わず。資料を後ほど読み込んで理解したい。

- [DeepDive] AWS SECURITY DEATH \m/ ~セキュ鮫様からのお告げ~ by Security-JAWS
資料

JAWS DAYS 2017 Security-JAWS発表資料 // Speaker Deck


セキュリティ関連でも何か検知して何かを処理する場合は
Lambdaを使うというのが勉強になった。オンプレでのシェルやバッチ相当の汎用性がある。