radioc@?

レディオキャットハテナ

【読書メモ】熊とワルツを

熊とワルツを - リスクを愉しむプロジェクト管理

熊とワルツを - リスクを愉しむプロジェクト管理

ソフトウェア工学界の巨匠トム・デマルコ氏とティモシー・リスター氏によるリスク管理の名著。古典と書こうとしたが2003年とのことで古典というほど古くはない。とはいえ、ソフトウェア開発の書籍でこれだけリスク管理にスポットを当てた本はあまり無いのでいずれ古典的名著と呼ばれる日が来るのは間違いないだろう。ソフトウェア開発をマネジメントするうえでは必読書と言って良いのではないかと思う。

本書の後半ではリスク軽減の方法としてインクリメンタルな開発の重要性を挙げており、その思想はアジャイル開発の手法に受け継がれているようにも感じる。言い換えればリスク管理の側面でアジャイル開発のルーツの1つとも言えるかもしれない。個人的にはじっくり読むには非常に良いタイミングでした。

なぜリスクを管理するのか

リスクのないプロジェクトには手をつけるな

リスクと利益は切っても切れない関係にあるので、リスクのないプロジェクトに手を出しても何も得るものはない。

リスクとは

  1. 将来起こりうる出来事で、望まない結果を生むもの。
  2. 望まない結果そのもの。

リスク管理とは1を管理すること。

問題とは

既に発生したリスク。リスク管理の反対を「危機管理」といい、問題が発生した後に何をすべきかを考える。

リスク移行

リスクが問題になることを「リスク移行」といい、リスクが「実現」したという。

リスク管理の各要素

  • リスク発見
    • まずリスクにかんするブレーンストーミングを行い、次にリスクを選別する。さらに、プロセスを継続するしくみを導入する。
  • エクスポージャー分析
    • それぞれのリスクが実現する確率と、それによる影響を数値化する。
  • 危機対応計画
    • リスクが実現した場合に何をすべきか計画する。
  • 軽減
    • 計画した危機対応措置が必要な時に実行でき、効力をもつように、移行前にとるべき対策をとる。
  • 継続的な移行監視
    • 管理するリスクを追跡し、実現しないかどうかを監視する。

デンバー国際空港再考

1993年に開港する予定だったデンバー国際空港(DIA)の自動手荷物処理システムが完成せず、莫大な遅延コストが発生したというソフトウェア開発の失敗事例。

※参考

agnozingdays.hatenablog.com

プロジェクトが失敗した原因は、DIAのリスク管理の方法にあるのではない。リスク管理の努力がまったくされなかったことにある。

リスクを管理すべき理由

  • 積極的にリスクをとれるようにする
  • 不意打ちを防ぐ
  • 成功するプロジェクトを作る
  • 不確定要素を限りあるものにする
  • 最小限のコストによる保険である
  • 目に見えない責任転嫁を防ぐ
  • 一部が失敗したプロジェクトを救える
  • 人材の成長機会を高める
  • 管理者への不意打ちを防ぐ
  • 注意すべきところに注意を向ける

リスク管理の方法

不確実性を数量化する

プロジェクトの完了について、縦軸に確率、横軸に時間をとったとき以下の3点を曲線で結んだ図を「リスク図」という。

  1. 可能性は極めて低いが最も早く完了する日
  2. 可能性が最も高い日
  3. 可能性は極めて低いが最も遅く完了する日

1をナノパーセント日と呼ぶ。

ソフトウェア業界全体でみると、不確定幅はNまでの期間の150から200パーセントである。

※参考

http://pcmdays.cocolog-nifty.com/blog/2006/09/post_5a24.html

リスク管理のしくみ

きのうの問題は今日のリスクである

過去に起きた問題を元に新しいプロジェクトのリスク・リストを作る。

リスクについてできること

  • 避ける
  • 抑制する
  • 軽減する
  • かわす

「かわす」は何もしなかったがリスクが実現しなかったこと。

リスク管理は、プロジェクトについて心配することとは違う

リスク・エクスポージャー

リスクの抑制コストの期待値。

リスク・エクスポージャー=コスト\times確率

コストのかわりに時間的なリスクにも使える。例えばプロジェクトが5ヶ月遅れるリスクが20%の場合はリスク・エクスポージャーは1ヶ月。

ショートストッパー

発生すると何もかも犠牲になって進めなくなるような自分では手に負えないリスク。リスクを監視する必要はあるが、自分が管理するのではなく上司や会社の上層部が管理するように正式な儀式を行って託す。

リスク管理の手順

9つのステップを実施する

  1. リスク発見プロセスによってリスクを調査する
  2. ソフトウェア・プロジェクトのコア・リスクが調査に含まれていることを確認する
  3. 個々のリスクごとに次の作業を行う
    • リスクに名前と番号をつける
    • ブレーンストーミングによって、そのリスクの移行指標を特定する
    • リスクが実現した場合にコストとスケジュールに与える影響を推定する
    • リスクが実現する確率を推定する
    • そのリスクの時間的、資金的なエクスポージャを計算する
    • 移行が始まった時にとるべき危機対応措置を事前に決めておく
    • 選択した危機対応措置を実行できるように、移行の前にとるべき軽減措置を決める
    • 全体的なプロジェクト計画に軽減措置を追加する
    • ドキュメント化する
  4. ショートストッパーをプロジェクトの仮定条件として指定し、上層部に引き渡す儀式を実行する
  5. リスクがいっさい実現しないものと仮定して、最初のスケジュール見積もりを作成し、ナノパーセント日を決定する
  6. 社内と業界全体の不確定要素を使って、Nから始まるリスク図を作成する
  7. リスク図を使って約束を発注者に伝える
  8. リスクが実現したり終了したりしないか監視し、実現したときには危機対応計画を実行する
  9. プロジェクトの期間中、あとから出現したリスクに対応するためリスク発見プロセスを継続する

RISKOLOGY

リスク評価のツール

Riskology Home Page

※メモ

Rで実装

smrmkt.hatenablog.jp

リスク発見プロセス

  1. 破壊的結果のブレーンストーミング
    • 悪夢に絞って考える
    • 水晶玉を使う
    • 視点を変える
    • 誰も責任のない不幸
    • 非難すべき失敗
    • 部分的な失敗
  2. シナリオの構築
  3. 根本原因の分析

共存共栄モデル

  • 利害関係と特定し勝利条件の対立や緊張を探る

ソフトウェア・プロジェクトのコア・リスク

  • 内在的なスケジュールの欠陥
  • 要求の増大
  • 人員の離脱
  • 仕様の崩壊
  • 生産性の低迷

リスク管理の力学

天罰期

  • リスクが問題として顕在化し問題を認識するプロジェクトの中盤ごろ

進捗メトリック

  • 境界要素の決定
    • データの流れからシステムの境界を明確化する
    • 仕様の崩壊のコア・リスクを防ぐ
  • EVR(現在稼得価値)
    • 実質的な進捗状況を表す指標(完成度%)
    • 仕様の崩壊意外の4つのコア・リスクの影響を追跡する

インクリメンタル開発

  • 設計をほぼ完全に行い、サブセットごとにインクリメンタルな開発を行う
    • 進捗メトリックの重要な拠り所
    • EVRをメトリクスに使う

インクリメンタル開発計画

  • 詳細設計図
  • 作業分解図(WBS
  • バージョン受入検査表

究極のリスク軽減戦略

究極のリスク低減は少しでも早く着手すること

数量化の方法

投資収益率=\frac{価値-コスト}{コスト}

リスクのことだけを考えると、リスクをどこまでとるべきか、理由を示して説明できない。

コストと効果は同じ精度であらわす必要がある

参考

qiita.com

yabit.hatenadiary.jp

【勉強会メモ】Osaka Mix Leap Study #21 - Server Side Kotlin

yahoo-osaka.connpass.com

  • 日時:2018/08/09(木) 18:30 〜 21:00
  • 場所:ヤフー株式会社 大阪グランフロントオフィス

KotlinといえばAndroidの開発言語というイメージが定着しつつありますが、実際には今回のLTでも話がありましたがマルチプラットフォームに対応した言語です。サーバサイドKotlinの話は時々聞きはしますが、どうなんだろう?ということで興味を持って参加しました。

実際にはDBアクセスまわりなど、サーバサイドを全面的に置き換えるにはまだ課題がありそうですが、ヤフーさんのように既に部分的にKotlinへの置き換えが進んでいる事例は思ったよりありそうだと感じました。イメージ的にはAndroidアプリ開発者がサーバサイドもKotlinで書きたいというモチベーションで導入しているのかと思っていましたが、PHPからKotlinへの置き換えというケースは少し意外でした。しかし現地の他の人からも少し話を聞いてみると言語仕様的にPHPからKotlinはそれほどハードルが高くないとのこと。確かにKotlinの型推論などはPHPerからするとJavaよりとっつきやすいものなのかもしれません。

今回、遅れて参加したりいろいろあってメモが雑ですがご容赦ください。

Kotlinのサーバサイド事情を俯瞰する

@ngsw_taro さん

Ktor(KotlinのWebフレームワーク)

github.com

Exposed(DBアクセスライブラリ)

github.com

Koin(KotlinのDIライブラリ)

github.com

2. Spring Framework

  • Kotlin x Spring
  • Web Fluxに着目

※メモ

qiita.com

  • Reactorのコルーチン
  • zip とかのAPIを覚える必要ない

※メモ

www.cresco.co.jp

3. Spring Fu

github.com

まとめ

  • Spring Bootは王道
  • コルーチンのおかげでReactorをしらなくてもOK
  • Spring Fuは開発途上
    • DIが内蔵されているのがいいかも
    • REST API前提
    • Open APIで使用を定義してからコントローラのコードを自動生成するのが普通?
  • 気になるのはDBアクセス周り
    • (実際のプロジェクトではExposeはまだ使いにくい)

サーバーサイドKotlinとSpring5の Kotlin support

@bulbulpaul さん

speakerdeck.com

Yahoo!カレンダーの技術ポートフォリオ@Server Side

  • インフラ:openstack⇒Cloud Foundryとk8s
  • 言語:phpJava⇒KotlinとJava
    • 最終的にはKotlinだけにしたい

なんでKotlin?

  • 制約と規律
    • Null Safe
    • sealed class
  • 高い利便性
    • 型推論
    • Smart Cast
    • data classが便利
    • IDEのサポートが強力
  • 巨人の肩に乗れる
    • Javaのエコシステムを使える

⇒開発が楽しい!

利用技術

  • Javaライブラリ
    • Athenz(認証/認可)(米Yahoo製)
    • Pulsar(MQ)
    • Hystrix(サーキットブレーカー)
  • Kotlin対応ライブラリ
    • SpringBoot(Fw)
    • Moshi(Json

ライブラリのKotlin対応

  • サポートされていないからKotlinが動かないことはない
  • Kotlinらしいコードで書けるための処理対応
  • 場合によってはJavaとの境界でNull Safeが守られない
  • GsonではNullSafeの定義をしてもNullが入ることがある

  • Spring Boot

  • Spring Fu
  • Spring Initializr
  • Spring Boot v2

Kotlin Support

  • idikomatic Kotlin code
  • Annotations
  • RouterFunctions
  • Bean definition DSL

Kotlinらしいコードが書ける

  • Extension functions
  • Reified type parameters
  • Javaコンパイルで消えてしまうジェネリクスの型をinline展開して処理中に参照する
  • Classで受け取る処理が多いので細々としたところの記載がKotlinらしく書ける

まとめ

  • SpringBootはKotlinの特性を邪魔せずに書ける
  • Kotlinはサーバサイドでも十分活用できる
  • Javaのライブラリも問題なく使える

LT

KHipster ~JHipsterで始めるKotlin Web プログラミング~

@s_kozake さん

speakerdeck.com

JavaのScaffoldツール(例えばSpringBoot+Angularの環境のようなアプリの雛形を自動生成してくれる)JHipstet の紹介と、それのKotlin版であるKHipsterの紹介。

github.com

KHipsterはまだ開発中(現在 v0.5.0 )なのでデフォルト設定を変更すると動かないので注意が必要とのこと。

multi platform kotlin

Multiplatform Projects - Kotlin Programming Language

Kotlinのマルチプラットフォームについて

マルチプラットフォームのサービスのドメイン層をDDDで設計してKotlinで実装するための考え方について本家サイトに公開されている解説を元にまとめた内容の発表。

  • 環境構築が大変
    • gradleとwebpack連携など

javaタヒねとさけんでた

@furusin_oriver

Kotlinのコードの書きやすさ、見やすさについて。 Arrayの使い方でJavaだと for(int i = 0; i < list.size(); i++){ } のような煩雑な書き方をしないといけない。Kotlinは快適という話。

【勉強会メモ】総関西サイバーセキュリティLT大会(第10回)

sec-kansai.connpass.com

  • 日時:2018/08/08(水) 19:00 〜 21:00
  • 場所:MOTEX大阪本社

セキュリティ現場の表話、裏話

富士通セキュリティマイスター かやまこうせつ さま

  • LTのメッセージ
    • 縁の下のエンジニアのいいとこ探して応援できる社会へ何かできないか
  • 葛藤
    • セキュリティを全面に押し出したかっこいいところや、危険を煽る内容がクローズアップされすぎていないか

1. ランサムウェア Wanna Cry

  • うっかり払ってしまいそうな身代金
  • 現場「あのコンピューターもつながってたの?」
  • バスの掲示板の裏で動いているPCなどもファイル共有設定されていた

裏:つながる時代を顕在化させたWannaCry

2. 人材育成

  • セキュリティ人材育成の取り組み
  • 現場は人材育成しているつもりはない

裏:人材育成は場づくりから

  • フィールド領域
    • 現場の人
  • エキスパート領域
    • セキュリティアナリスト
  • ハイマスター領域
    • シニアセキュリティ

ハイマスターが下から現場を支えるようにする

3. サイバーレンジ

裏:サイバーレンジは場の一つ

  • サイバーレンジを買うだけでなくそれをどうやって扱うか

人を中心とした設計

  • タレントは自分の範囲でしか仕事をしない
  • ナレッジをどうやって集めるか
    • 貯める場所を用意しないと散在

※メモ

tech.nikkeibp.co.jp

4. 公衆無線LAN

www.itmedia.co.jp

www.sankeibiz.jp

利害関係者を洗い出して議論するのが大事だ。法整備という話も出てくるかもしれない

裏:そんなん言ったかなぁ

  • 利害関係者を集める
  • 緩和するための法整備もしてはどうか

5. 国産プラットフォーム

  • 日本vs海外
    • 減点vs加点
    • 障害対応vsいいね
    • ムエンゴvs谷町衆
    • 粗相無いようにvsチャレンジ

第一部まとめ

縁の下のエンジニアの裏の頑張りを拾い続けます

第2部 セキュリティ競技 Hardening 100 Value x Value に参加してきた

  • 競技の説明
  • 初動・体制・情報共有・チームワーク
  • インシデントレスポンス
  • ビジネス稼働率向上の取り組み
  • ログ分析
  • Hardening、進捗管理
  • マーケットプレイス活用の試み
  • ビジネス活性化の試み
  • 総括

内幕はそんなきれいじゃない

13時半までリモートデスクトップが繋がらなかった

⇒判断に徹する

オチ:RemoteDesktopツールのバージョンが違う

  • 技術者と同じ目線で会話できるマネージメント層
  • 技術わかる、縁の下のエンジニアの裏まで理解してあげられるマネ大事
  • たましいは現場に宿る

締め

  • 現場ではいろんな人がいろんな視点で頑張っている
  • できて当たり前じゃない
  • だからそんなエンジニアを応援したい

トークセッション セキュリティ競技の意義 

Yahoo太田さま・富士通かやまさま・tktkのSeraphさま

以下のテーマについてトーク。詳細は割愛。

CTF

キャプチャー・ザ・フラッグ

CTFの例

※メモ

セキュリティ競技CTFって何?

Hardeneing

  • 本家(年2回主に沖縄)
  • Mini(不定期)
  • Micro(不定期)
  • Yahoo(年1回)

情報危機管理コンテスト

wasforum.jp

CYDER

CYDER | ナショナルサイバートレーニングセンター | NICT-情報通信研究機構

アルティメットサイバーセキュリティクイズ

www.seckansai.com


関西の産官学による情報セキュリティ人材育成の取組(案)

藤田さん

関西で情報セキュリティを取り組んでいる人にもっと光を当てたい

  • 政府方針
  • 戦略マネジメント層の育成・定着
  • サイバーセキュリティ戦略⇒東京の話

地域でこそ、この問題は深刻

  • 地域で情報セキュリティセンスをもった人材の裾野を広げることが重要

具体的取組

  1. リソース足りないならみんなで補完しようというカタチづくり
  2. 学校や企業では教えてくれない、原理・原則講座シリーズ
  3. 情報セキュリティ人材へのスポットライト当て

今秋スタート予定。完全ボトムアップ

IT知識ゼロの組織がマルウェアに感染した話

村上さん(京都産業大学2回生)

  • 委員会の会議の場でPCが壊れた
  • 明らかにランサムにやられてそう

対策

  • ネット切断、電源切断
  • 通常の業務と同じように直属の先輩⇒学校に報告

解決しなかった

  • 幹部→学生部→情報センター→PC対策
  • 学生部で立ち消え
    • 曖昧な報告

CSIRTがマスト

  • インシデント対応は通常の組織構造では対応が送れたり適切に行えない危険
  • 組織にとらわれない動ける人
  • インシデント対応ができる人
  • 上の人や関わったことのない人たちでもビビらず対応しないといけない

裁判のIT化に立ち向かう

伊藤さん(弁護士)

日本の裁判所の文化

  • Fax、印鑑
  • 事件管理システムはClose環境で使いにくい

IT化

  • 3つのe
    • e-提出
    • e-法廷
    • e-事件管理

ハードル

  • 法律マターか最高裁判所マターか
    • Web会議による審議→裁判の公開?
    • 日本は本人訴訟が多い
  • IT化対応できない人は紙?
  • セキュリティが問題になる

便利になった先に何があるか

  • 判決のデータベース化
    • ビックデータ活用
  • 利便性とセキュリティ

セキュリティと利便性のあるシステム作れる方

  • 最高裁が求めています
  • 実装をしている皆様の声が必要

クレジットカードを不正利用された話

MORITAさん

speakerdeck.com

タイムライン

  • 10月にカード会社から電話
  • 8月に言った

被害

  • 10日間
  • 80件
  • 明細3ページ

  • Google Midasという謎の決済情報

    • 1ドルx40連打
  • Facebook→ゲーム
  • レンタル倉庫→滞在先の近く

blackhatの出張

  • セキュリティのエンジニアがセキュリリティの出張でセキュリティの被害に…

決済に必要な要素

  • クレカ番号
  • 有効期限
  • セキュリティコード

店員がバックヤードでカード情報取得

対策

  • セキュリティシール(開封防止シール)
    • セキュリティコードを隠す

まとめ

  • ITセキュリティも大事だがまず物理セキュリテイ
  • 内部犯行も考慮したセキュリティ脅威分析は必須
  • 大手クレカ会社のサービスの信頼性

マッスルタワーに挑んでみた

chocopurinさん

Micro Hardening

ドラゴンボールに例えると

参加動機

  • 技術的な刺激
  • 本家Hardeningはスケジュール合わず

当日

まとめ振り返り

  • 45分の短い時間だがいろんな分野の攻撃がくるのでインターバル時の疲労感
  • 回を重ねるごとに対策ができているのを実感できる
  • 事前資料はよく読む
  • システム運用は知っておく

【勉強会メモ】re:Union 2018 Osaka

jawsugosaka.doorkeeper.jp

  • 日時:2018-08-05(日)10:00 - 19:00
  • 場所:エムオーテックス新大阪ビル

大阪北部地震で中止になったAWS Summit 2018 Osakaで予定されていたセッションを再構成した、JAWS-UG主催の仕切り直しイベントです。残念ながら全てのセッションに参加することはできませんでしたが参加したセッションだけメモを残しておきます。

個人的にはLift-and-Shiftの事例から始まり未来のエンジニアにまで言及されていた部分が刺さりました。あとはNintendo SwitchもガッツリAWSを使っているんだなぁというのも改めて時代を感じました。

SUMMIT TOKYO re:cap〜基幹システムの移行とクラウドネイティブ構築、それぞれの事例のお客様をお迎えして〜

亀田 治伸様(アマゾン ウェブ サービス ジャパン株式会社)

Summit Tokyoで発表された東京リージョン対応サービス

大阪リージョン

Day1 Keynoteサマリー

  • リージョン間の通信はインターネットに出ることがあったがinternalな通信ができるようになった
  • Cloud Journey
  • Lift-and-Shift
    • システムのクラウド移行
    • いきなりコスト削減を目指さない
    • 将来の最適化&進化

Cloud + Community ⇒ 情シス2.0

友岡 賢二様 (フジテック株式会社)

The End of Corporate Computing

  • 電気の発電機を持つ人は今やほとんどいない
  • データセンターを持っているのは発電機をもっているようなもの

伝統的手法での企業データセンター

  • 自社でつくるとめちゃくちゃ大変でコストかかる

固定リソースの限界

  • 好きな時に好きなだけ立ち上げてあとで消せる
  • Pay per use
  • 拡張性・伸縮性

調達コスト

  • 構築に最低6ヶ月ぐらいかかる

フジテックの情シス(88 servers)事例

  • 初期費用
    • -95%
  • 運用費用
    • -42%
  • サーバレス
    • 19,600円/年
    • Lambdaにしたら100円/年

クラウドジャーニー

  1. Lift & Shift
  2. Re-Sizing & COst Optimization
  3. Serverless

Enterprise IT's Challenges

  • 人材育成…アプリ、インフラの分離運営の限界
  • DBMSロックインとクラウド化への険しい道程
  • AWS大阪”ローカル”リージョンの活用と発展

E-JAWS-UG

  • 120企業
  • コミュニティにエンジニアを放流しよう

Lift-and-Shift

  • システムの維持コスト最適化
  • 生産性の向上

AWS Well-Architected

aws.amazon.com

TCO計算ツール

  • Cloud Economics(投資効果算定支援)

aws.amazon.com

AWS Support

  • お客様をサポートするチーム
  • Trusted Advisor

aws.amazon.com

クラウドネイティブ


高橋 真知様(株式会社 Stroly)

stroly.com

位置情報サービス - ターゲットやテーマを決めたマップ - 看板や紙で配布→もらっても位置がわからない→Webサービス化 - アナログ地図は世界中にバラバラ→位置情報と地図を連動させる

誰でも地図を一括登録

  • アプリではないのですぐに利用できる

京都市の事例

  • 260箇所の地図看板にQRコード設置
  • 誰がどの看板を見たかもわかる

AWSサーバレスアーキテクチャで実現

参考

www.slideshare.net


クラウドネイティブなアプリケーション開発

  • 仮説立案⇒開発⇒検証⇒くりかえし

AWS loft tokyo(目黒)

aws.amazon.com

機械学習

  • S3でデータを捨てる必要がなくなる
  • 蓄積されたデータは分析されビジネス強化に使われる
  • データ分析⇒ビジネス設計⇒製品・サービス設計⇒提供開始⇒くりかえし
  • 機械学習がサイクルを加速させる

BUILD ON

参考: AWS BUILD ON


参考

AWS Summit Tokyo 2018 資料・動画一覧 - |AWS


Lift-and-Shift による失敗しない AWS 移行のやり方

大石 良様(株式会社サーバーワークス)

  • 2007年AWSのテスト利用を開始
  • 2008年に社内サーバ購入禁止
  • 2009年AWS専業インテグレーター

日本赤十字AWS化支援事例

www.serverworks.co.jp

AWSパートナー

  • Premier
  • 上位0.3%

どうやってクラウドに移行するか

Lift-and-Shift

  • 既存のサーバーやシステムをで移行
  • クラウドらしいサービスを活用してビジネスのデジタル化を推進

いきなりキラキラに移行しようとするとやけどする

  • 運用手順変更
    • 合意形成、手順作成、組織変更などが必要
  • AWSのアップデートの速さ
    • やっている途中で新しいサービスが出たりするとやる気を失う

AWSの隠れたメリット

  1. ネットワーク移行しやすい
  2. 仮想マシンが移行しやすい
  3. アプリケーションが移行しやすい

関西(西日本)の移行事例

災害はいつくるかわからない


川村 暢様(株式会社NTTスマイルエナジー)

オムロンとの合弁会社

nttse.com

Lift-and-Shit戦略を実行した実例

AWSを使おうと思ったきっかけ

  • 最初はプライベートクラウド
  • ビジネスのスピード感にインフラが追いつかなくなった
    • センサーIoT→センサー数が数万に急増
    • ライセンス料がかかる
    • AWSを使おう

AWSを使ってみた感想

  • コスト面
  • 環境を簡単につくれる
  • あとで増減できる
  • いったん作ってみて出せる
  • エンジニアのモチベーションが上がった

Lift-and-Shiftをやってみてどのように評価されているか

  • 少なくとも数年単位のスケジュールでやっていたものが5ヶ月でできた
  • ほとんどインフラを知らないメンバーが2,3週間で仮想サーバの移行ができた

今後の展望

  • 再生可能エネルギーの割合が増えてきている
  • 一極集中型の発電所が分散型になると予想
  • IoTのようなサービスが必要
  • AIのようなものも必要になる

キラキラ系を目指す


金融機関の事例

琉球銀行

  • Lift
    • 分散系サーバ、Webサイトの移行
  • Shit
    • セキュリティ対策としてログを分析
    • FAQのAlexa対応

Cloud Automator

  • AWS運用を自動化

cloudautomator.com

新しいアーキテクチャへの移行支援

なぜクラウド、なぜAWS

人材価値の変化

  • エンジニアの価値が相対的に増大
  • 若者層の価値が相対的に増大

不足する人材

  • 優秀なエンジニア
  • 若手人材

企業の変化

  • 会社が社員を選別する時代から社員が会社を選別する時代へ
  • 企業は若手がおもしろがり未来のあるテクノロジーを選択する時代へ

何を自社で行い何を外部に委託するか→AWSをIT基盤にする


※参考

クラウドで実現する「開発レスアーキテクチャ」 3 つの事例

Nintendo Switch (TM) 向けプッシュ通知システム「NPNS」

渡邉 大洋様 (任天堂株式会社)

※資料

Nintendo Switch (TM) 向けプッシュ通知システム「NPNS」

NPNS

  • プッシュ通知システム
  • Nintendo Push Notfication Service
  • 常時接続を使用

NPNS利用例

  • フレンドのオンライン通知
  • Nintendo みまもりSwitchでの設定変更
  • ゲームDL後に完了メッセージ

性能要件など

  • スケーラビリティ:1億台に備える
  • 可用率:AWSリージョン規模の障害未満は可動
  • 遅延:数秒(正常時)、数分(異常時)
  • インフラ費用:適切な範囲に抑える

構成要素

  • XMPP Cluster
    • Switch向け常時接続、通知
  • Consumer API
    • ID管理
  • Provider API
    • サーバ間連携向け、通知送信要求

※下2つはREST API

XMPP Cluster採用技術

  • ejabberd
  • Erlangで書かれたOSS
  • クラス構成のXMPPサーバ
  • 大規模な利用実績が多い
  • RDS for MySQL
  • 高負荷時のレプリ遅延が少ない
  • ElastiCache for Redis

Consumer/Provider採用技術

  • RoR
    • 社内での開発・運用実績から
  • Amazon Aurora
    • RDS for MySQLから乗り換え
  • 柔軟なスケール

その他

  • Amazon SQS
  • ELB
  • Route53
  • Consul
  • クラスタ動作、ネットワーク分断に強い
  • ejabberdのFailure Detection

インフラ設計

クラウド選定

  • AwsをIaaSとして利用
    • 社内実績
    • メンバーの経験・スキル
    • マネージド・サービス
  • 配置
    • シングルリージョン
    • ネットワーク安定性、リソースの利用効率向上
    • Multi-AZ

XMPPクラスタ分割

  • スケーラビリティ
  • 安定性
  • 障害の局所化
  • 運用効率
    • 小さくデプロイ(カナリアリリースできる)
    • パラメータをちょっとずつ変えて様子をみるなど

XMPPのロードバランス

  • ELBは不採用
    • Classic Load Balancer
      • 常時接続に使えない
    • Application Load Balancer
    • Network Load Balancer
      • 検証次期とリリース次期があわない
  • 直結+DNSラウンドロビン
    • Route53に全ノードのAレコードを登録
    • ConsulがRoute53のレコードを更新
  • ディスカバリは用意しない
    • 外部向けI/Fは増やさない

技術詳細

クラスタ維持

ejabberdを2方向から死活監視

  • Consul
    • すぐ反応
  • Auto Scaling
    • 慎重に様子見

デプロイ

  • Blue/Green Deploy
    • ASG単位でドメイン切り替え
    • 新旧両方を1つのクラスタ
    • 旧ノードからユーザーを一定レートで追い出す=ドリップ処理

ドリップ処理

  • スムーズな切り替え
    • 接続を少しずつBlue→Greenに移動
  • 常時接続では接続処理が最も高負荷
    • 再接続タイミングを分散させたい
    • 切断期間は短くしたい
  • やっかいな点
    • デプロイが長時間化→今は約2時間
    • インスタンス費用がその間2倍に

ドリップ処理の自動化

  • Auto Scaling→Lifecycle Hook→CloudWatch Events→Run Command→EC2 Instance

省メモリ化

  • インフラ費用を抑えたい
    • ejabberdを省メモリ化
      • OpenSSLのメモリ削減&開放
      • hibernate前にリソースを開放
    • r3.largeで1台あたり72万接続
  • ところが
    • CPUもメモリも秋があるために接続数が増えない
  • Security Groupの制限を回避
    • セッションの上限にあたっていた
    • Security Groupを無効に
    • 限界まで設定可能に
  • セキュリティ 外部アクセスはNetwork ACLsで制限

TCP切断対策

  • 途中経路でのいy増切断を防ぐ
    • 無通信期間にKeepAlive(L4,L7)
    • 最適感覚を本番環境で実験
  • TCP KeepAlive(L4)
    • TCPヘッダのみの特殊パケットを定期的に送信
    • time:ユーザーごとに可変
    • interval x probes:クラスタ間で対照実験
      • 10 x 2→15 x 10
      • 切断を40%削減
  • アプリケーション KeepAlive (L7)
    • データを入れたパケットを定期的に送信
    • 送信間隔:クラスタ間で対照実験
      • 送信無し→65秒間隔
      • 切断を50%削減

ふりかえり

12月の同時接続数増大→通知送信数は削減できている 規模

  • 約700万同時接続
  • 約2万通・秒
  • 約l200億通/月

AWSの異常 - 発生した異常 - 局所的なネットワーク異常 - RDS I/O遅延 - EBS遅延 - EC2インスタンス異常停止 - NPNSサービスへの影響 - AZ冗長等によりサービスは正常稼働を維持

Erlangでの運用

良かった点 - 安定性 - VM,クラスタ、プロセス監視ツリー - メモリ効率 - 並列性 - hot code loading

ejabberd改造内容

  • 並列性、安定性、対象外制
  • 省メモリ化
  • 独自機能

まとめ

  • 必要要件を達成
  • AWS起因のサービス停止は無かった
  • サービス規模は順調い成長

今後の展望

  • NLB
    • Cross-AZ指定ができるようになった今こそ
    • XMPPクラスタロードバランサに利用
    • consulを取り外してシンプル化
  • Fargate
    • Consumer/Provierに採用

【読書メモ】ライト、ついてますか

ライト、ついてますか―問題発見の人間学

ライト、ついてますか―問題発見の人間学

副題に「問題発見の人間学」とある通り、問題に向き合い、解決に向けて思考を巡らせるための考え方を人間学の側面からやや辛辣なユーモアを交えながら解説している。

初版は1987年の古典的名著だが、出版年は意識して読むほうが良い。Amazonのレビューにもいくつかコメントを見かけたが、まず翻訳がわかりづらい。また、エレベーターや計算機という言葉は現代のそれとはやや違うものとして書かれているので注意が必要。これらは出版された年代を考えれば仕方ない面もある。それを考慮して読めば、問題解決に向けた普遍的な考え方や思考の巡らし方について著者が述べる本質的な部分を読み取ることができて問題解決力を養うためのヒントが得られるはずである。

何が問題か?

新築タワービルのエレベーターが遅いというエピソード。エレベーターが遅いのが表面的な問題ではあるが、ビル入居しているオフィスの従業員、オフィスの経営者、ビルのオーナーなど、立場によって問題の本質は異なる。

  • 「何がまずいか」をどう決めるか?
  • まずいのは何か?
  • そのために、何ができるか?

問題とは、望まれた事柄と認識された事柄の間の相違である

望まれた事柄か認識された事柄かのどちらかを変えて相違をなくすことで問題はなくなる。

問題は何なのか?

ある11件の資産の入札プロジェクトのエピソード。それぞれの資産には様々な条件があって、入札に関わる4社がそれぞれ価格をつけると400万通りになり、その組み合わせの中から最も最適なものを選ばなければならない。

解法を問題の定義と取り違えるな。ことにその解法が自分の解法であるときには注意

複雑な問題を解くことが問題の定義ではないということ。

正しい問題定義が得られたという確信は決して得られない。だがその確信を得ようとする努力は、決してやめてはいけない

「究極の解答」は存在しないが、「問題は何か?」を問い続けることが重要。

問題は本当のところ何か?

すべての解答は次の問題の出所

ある問題を解くために状態を変えると別の問題を発生させることになる。 問題の転嫁 によってより小さな問題に状態を変えることができるが、たいていの場合は新しい問題が無意識的に作り出される。

新しい視点は必ず新しい不適合を作り出す

解決策を実施する前にこの視点を持っておく。不適合とは「その解決策とつき合わなければならない人間とうまく合わないような解決策」のこと。問題の当事者ではない「設計家」はたくさんの不適合を作り出してしまう。

同じ言葉を同じように理解しているという保証は決してない

行間を読んで自分たちの都合の良い解釈をしたり、単語の使い方1つで全く異なる意味に取れてしまい大きな損失を出すこともある。言葉を表面的なものから意味のあるものにするためには「言葉遊び」や「辞書方式」のような「社会的過程」が必要である。

それは誰の問題か?

他人が自分の問題を自分で完全に解けるときに、それを解いてやろうとするな

自分たちの問題は自分たちが一番理解しているので自分で解くほうが良い。

もしある人物が問題に関係があって、しかもその問題を抱えていないなら、何かをやってそれをその人物の問題にしてしまおう

反対に自分たちでどうしようもない問題であれば、「私の問題」を「われわれの問題」に変えてみる。学生の増加によって大学の駐車場が不足してしまったので、専用の駐車場を持つ学長も問題に巻き込んでしまおうというエピソードで語られている。ただし、立場や考え方が違うとうまくいかないことも多い。

変化のために自分をせめてみよう、たとえほんの一瞬でも

自分自身の考え方を変えてみることで問題が簡単に解決することもある。

もし人々の頭の中のライトがついているなら、ちょっと思い出させてやる方がごちゃごちゃ言うより有効なのだ

書籍のタイトルにもなっている車のライトの問題が出てくる。設計者や技師は何もかも自分が面倒を見なければならないと考えて問題を複雑にしてしまう。実際には「ライト、ついていますか?」と言ってやるだけで十分な問題だったりする。

それはどこからきたか?

問題の出所はもっともしばしばわれわれ自身の中にある

入国手続き中に書類のコピーが一部紛失していることが発覚し、役人側が紛失した可能性も否定できないにもかかわらず、官僚主義的に書類の不備として扱われそうになるというエピソード。

自然に起きた問題は2つの理由で最悪なものである。

  • どうしようもないという気持ちに陥りがち
  • 自然は我々に対して無関心で動機をもたないゆえに手に負えない問題を引き起こす

この問題はどこからきたのか?

という問いかけをすることで

問題を「自然」の領域から引き出して、建設的な思考と解決への行動、という領域に移すことができる。

著者らの経験によれば、問題が実は問題解決者自身に起因する割合は53.27%に及ぶ

「この問題はどこからきたのか?」を問いかけたとき、問題は「どこでもないところから来ている」可能性がある。正確にいえばそれは「その問題自体からきた問題」である。このようなどこでもないところから来ている問題を解決するためには、問題を出所に送り返す。

試験のような問題は背後に設計者がいて、むずかしいように設計されており、その問題解決はパズル解決となる。このような問題にどっぷりと浸かった者にとっては、自明な解答のほうが混乱させる場合がある。

われわれはそれをほんとうに解きたいか?

われわれはたいていの場合、何か問題を抱えていると感じている。

問題というのは人が望むところと、物事がどうなっているように見えるかとの差である

自分が問題を抱えていると知っているかどうかは感じかたの問題だが、何が問題かを知ることは別のことだ。何が問題かをわかっていれば解決するのは易しいが、分かっていると思っていても間違いのことがある。他人のために問題を解いてやるときは、たとえ計算機を駆使して問題を解いたとしても、その答えを知るまでそもそも何が問題かをわかっていないものだと認識しておくべきである。

ちょっと見たところと違って人々は、くれといったものをだしてやるまでは何がほしかったか知らぬものである

何がほしいか完全に知っていたとしても、問題はそれで終わりにはならない。時には問題のことを忘れてしまうのが最善の場合もある。

あとから調べてみれば本当に問題を解いてほしかった人はそんなにいないものだ

どんな問題であれ、本気で問題に手を付けようとする前に必ず発してみなければならない問いが

私はそれを本当に解きたいか?

である。解答が得られてみたらそれはちっともほしいものではなかったということもある。例えば問題解決者は、問題が解けたために失業するかもしれない。

魚、水を見ず

人は 順応する ものなので、問題について考える時、順応した物事は考慮から除外されやすい。問題解決者は他の関係者が無意識にその中で泳いでいる「水」をはじめから見ようと努力しなければならない。その水は問題が解けたとき、砂に変容するかもしれない。

まず汝自らに対して真実なれ。

問題解決は決して道徳的に中立の活動ではない。そのため問題解決者は問題を解く前から解答に至るまで、道徳的側面について考えてみる必要がある。

参考

68601090.at.webry.info