デブサミ参加メモ 2016
デブサミに参加したので軽くメモ。(かなり遅くなったけど。。)
- 【18-E-1】DevOps時代に明日から活かせるセキュリティ対策術
- 【18-A-2】現場から変えた”サービスの作り方” ～何を作るのかではなくなぜ作るのか～
- 【18-C-L】大規模 SPA ( Single Page Application ) を TypeScript と AngularJS を駆使して5ヶ月で作った話(昼食付き)
- 【18-A-3】myThingsからみたIoTの未来と課題
- 【18-D-4】Storeランキング上位におけるゲームインフラについて
- 【18-E-5】リアクティブ・アーキテクチャ～大規模サービスにおける必要性と課題
- 【18-D-6】開発者が押さえておきたいクラウドネイティブ時代のITインフラのトレンド
【18-E-1】DevOps時代に明日から活かせるセキュリティ対策術
- OWASP(Open Web Application Security Project)という団体の方のお話。
- セキュリティは大事というお話の後は、OWASPの成果物の説明。攻撃者は効率性を重視しているから、ちょっとしたセキュリティ対策でも十分効果があるとのこと。
- チートシートの日本語訳
- owasp asvs
- https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0ahUKEwiRqfWtloDLAhVGi5QKHYgDB6EQFgg0MAM&url=https%3A%2F%2Fowasp-asvs.googlecode.com%2Ffiles%2Fasvs-webapp-release-2009-jp.pdf&usg=AFQjCNGRTMCExoDuHyKgPFmSnkUX_Xvasw&sig2=LUFMGSgqDdjl5QwIcOiXVg
- ガイドライン。要件定義や設計工程でセキュリティを考慮しましょうとのこと。
- owasp zap
- OWASP IoT Testing Guidance
- OWASP IoT Testing Guidanceのガイダンス ｜ Developers.IO
- IoTにおけるガイダンス
【18-A-2】現場から変えた”サービスの作り方” ～何を作るのかではなくなぜ作るのか～
【18-C-L】大規模 SPA ( Single Page Application ) を TypeScript と AngularJS を駆使して5ヶ月で作った話(昼食付き)
www.slideshare.net
- サンドイッチ付きのランチセッション。内容はリリースまでの苦労話。技術的なことより、仕様が決まらないことが一番の苦労話だった。
- TypeScript, AngularJS 良い
- 絶えずリファクタリング。設計はなんどでも作り直す
- プルリクは溜め込まない
- わからないことは聞く
- Webエンジニアは2人。レビューを繰り返してコードが似てきた。後半のレビューの工数は少なかったとのこと
- iOS & AndoroidエンジニアもWebに参戦
- プルリクとペアプロでカバー
- プロジェクトオーナーとはいつでもどこでもコミュニケーションを取れるチーム体制を築く
- プロジェクトオーナーがとある事情？で現場と距離があったため、リリース日は決まっているが仕様がなかなか決まらない。
- 全員で仕様策定のためのカンヅメを敢行。プロジェクトオーナーにも会議に参加してもらいスクラムの一員として動いてもらうことで仕様を固めて間に合わせたとのこと
【18-A-3】myThingsからみたIoTの未来と課題
- 再びヤフーの人の話。myThingsを使うことで、現実世界の課題を解決するための足がかりができたという話。
- myThingsはIoTサービス同士を連携するもの
- 現在41のサービス間連携が可能で、そのうち10個くらいがIoTサービス。今後も増えていく予定
- 現実世界の課題を自然な形で解決できないか模索中
- 実際にフィールドワークとして、限界集落に調査しにいって水害や獣害の監視を行っているとのこと
- 何が解決できるのか、どんな課題があるのかは模索中という印象。
【18-D-4】Storeランキング上位におけるゲームインフラについて
- スクエニのインフラの人の話。backendはniftyを使っていて、毎週定例で顔を合わせて改善していっているらしい。全部入りサーバを用意して、運用をラクにした話。
- 上に乗るアプリが案件ごとに違うから、全部入り「サーバ」を渡せば解決という話か。
- 案件数多い、規模もでかい、開発体制も様々。開発自体は外注していて、言語も風土も異なるのが悩み。(案件でクロスしているわけではなさそう)
- クラウド基盤の安定性(niftyの話)について
- 問題解決への取り組みや即時対応ができるサポート体制がある
- 定期的なやりとり、課題解決提案、柔軟な対応など、長いお付き合いをしている(クラウド基盤側と定期的に顔を合わせてる)
- インフラ構築のスピードを向上させた話
- 今までは、「要件ヒアリング→検証→チューニング→ドキュメント化→サーバ展開」だったのを「事前検証→数コマンドで展開」に変えた
- all in one(全部いりサーバ)を用意。それをバージョニングしている
- 変更は管理者だけ、開発者はサーバを作成して使うだけ
- 必要の無いものは手動でオフにしている
- 運用中のコンフィグの変更はcapで行っている
- 今までは、「要件ヒアリング→検証→チューニング→ドキュメント化→サーバ展開」だったのを「事前検証→数コマンドで展開」に変えた
【18-E-5】リアクティブ・アーキテクチャ～大規模サービスにおける必要性と課題
www.slideshare.net
- リアクティブシステムの話。マイクロサービスより広い概念らしい。
- 分散化の話はいつもメリットより、デメリットに共感してしまう。。
- マイクロサービスについて(省略)
- リアクティブシステムについて
- 「即応性（Resiponsive）」、「耐障害性（Resilient）」、「弾力性（Elastic）」と「メッセージ駆動（Message Driven）」を備えたシステム
- マイクロサービスとの比較
- 非同期呼び出し、レジリエント(部分的な障害が発生しても全体に波及せず自立的に回復する)なシステム、メッセージ駆動ミドルウェアを重視
- リアクティブシステムの課題
- 大量データを扱う非同期データストリーム。データフローが決壊するとシステム全体のクラッシュに繋がる(バックプレッシャーで受けてから要求する数を指定するという回避もある)
- マイクロサービスのコスト
- 分散→プログラムが難しい
- 結果整合性→一貫性の維持が非常に困難
- 運用の複雑さ→大量のサービスの管理が必要
- 分散プログラミングのつらみ
