に参加したので感想などを…
その場で残したメモに多少手直ししたくらいのものなので、登壇者の発言もあれば、自分の感想もある ごった煮です。
資料まとめ
デブサミ2020、講演関連資料まとめ：CodeZine（コードジン）
感想など
13-D-1：LINEがプライベートクラウドを選ぶ理由
- 聴講のモチベーションは 最近プライベートクラウド(k8s)のシステムに少し関わっているから
- プラットフォームチームからのアプリチームへの関わり方についてのヒントがあれこれ
- Verda（ベルーダ）っていうのは基盤の名前ってことで良いんだよね？*1
- 基盤利用の在り方はチームメンバーをリーダーが管理するのと、スクラムによるチームで違いがあって良い
前者はベンダー集合体のようなチーム編成、後者は同じ会社メンバーであったりエンジニア以外で編成されたチームに、みたいに適材適所がある
前者は管理者にロールアドミニを持たせて権限管理しっかり（いろんな人がいるからね）、後者はメンバー一人一人に権限付与の権限を渡している（全員で１つの仕事をするからね） - 間違いは起きる前提のPFにしている
たとえばDNS登録時に レビューではなく仕組みでチェックする - 「なぜプライベートクラウド？パブリックで良いんじゃないの？」
Yesではあるけれど、クラウド管理者と開発時点で相談をしてベストアンサーを把握してから開発をする
プライベートクラウドの場合、新機能への調査をして適用させる
プライベートだとPFチームは開発するサービスに意識が向く。パブリッククラウドの利用だと「使い方」に意識が向く。
アドバンテージはPFチームのマインド - OSS活動（OpenStack）について
VM５３０００、ベアメタル３万の規模
スケールとハイパフォーマンスに関するコミットが多い
MQはRabbitMQを使っている
13-B-2：モノタロウがGCPで挑戦するデータドリブン・ECプラットフォーム〜持続的成長の舞台裏
- 購買に関わるコストを下げることが使命
- 1800SKU
- データマーケティングが成長の牽引
業界用語での検索も出来る（この辺りの工夫は面白いと思った）
それを仕組み化している（人力では不可能）データの集約して分析をしやすく
- データにIDをつけるなどもして一意性を追加で付与
- データの集約先はBigQueryにした。GCP使っているし協力なスケーラビリティ
- CDCによる安定したデータ連携
- 変更イベントをトリガーにしてBigQueyへ。変更から連携完了までは1分を目処に
- リアーキテクチャリングのポイントはデータのリアルタイム性
DBをHUBのように使うとスケーラビリティが悪くなる
MySQLへのストアを中心としたアーキテクトだから、という前提での話
（DB中心は 割とあった仕組みだと思うけど、今だったらメッセージ駆動な感じにするんだろうな。顧客価値へ直結しないというと言い過ぎかもしれないけど、多少の欠落があったとしても価値の減損が限定的な場合は結果整合性（もしくは整合性すら多少目をつぶっても）で良いと思う。）マイクロサービス化の目的はデータ活用（再掲）
13-D-3：サーバーレスなPCI DSS対応クレジットカード決済基盤システムを運用しながら、みんなでわいわいDIYの精神で、新しいモバイル決済サービス6gramを作っている話
- 長いタイトル
- 決済システム（PCI DSS対応）にはグローバルな「仕様」があって それを守らないといけない
- パスワードの変更サイクル（９０日）とかも、その範疇（なので 現在では意味が無いと言われている仕様であったも 対応しないといけない。へぇー）
- コンテナをReadOnlyで使うことでインスタンスを使わないので侵入不可な仕組みしてしまおう（発想が面白い
- 開発チームはPM、開発、デザイナー含めて10名以下（だったと思う。メモに残せていなかったけど、いずれにしても決済の仕組みと考えると びっくりするレベルの小部隊という印象
- クレジットカードを共有ウォレットとして使えるサービスも。今は招待制（このあたり、かつてのmixiっぽい？
13-A-4：我々はZOZOTOWNのクラウドジャーニーを通じて何を学んだのか？
- 川崎さんってMSの人では？と思っていたら やっぱりそうだった
- ピーク、オフピークの差が激しい
- スケールへの影響が大きく複雑性の低いバックエンドからリプレース
- ストアドコールからAPI（AKSベース）に更改、」しかも参照系から
- 「アプリケーション回復性パターン」
- クラウドリソースを過信してはいけない。大量リソースが必要なことが予測できている場合は事前にクラウドベンダーに相談をすること
- キャッシュが100%に張り付いたときにアプリの挙動が想定外にレスポンスが返ってこなかった（対策はとっているつもりだったけど結果としては十分ではなかった）
- クラウドは安くはない、従量課金モデルは長期的には高い
だからクラウドはやめましょうではなくて、短期的な課金だけで判断するものではないということ - 話は クラウド対応の教科書的な事例と言っても良いことばかりだったけど、それを実体験を通じて得た言葉として意味はあったと思うし、Azureの有識者であろう人が実感として発信していることに意味があると思う。
13-A-5：楽天がモノリス→マイクロサービス & オンプレ→クラウドで経験した光と闇
- 元の構成：Iaasベースで永続化は物理ディスク
- Azureベースにリプレース
- CDNをAzureの外に出したのは課金が問題だったから（確かにクラウドの中に配置するとコンテンツ配信都度 従量課金される
- AzureMySQLはHW障害により予告無しに中断する
ミッションクリティカルには使えないが、７２時間前にメンテナンス通知を送るように対応中 - DBの可用性を考えるならMessagingの活用も視野に入れると良いだろう
- マイクロサービスにした理由は利用するメソッド（GET）以外はリクエストが少ないということがあった
- URL単位でデプロイする仕組みにしたら対応範囲が局所化できる（ので、メソッド単位でPodを作っている
- コンパクトなので起動が早い
- Helm2を使っている
- Kiali、ネットワーク監視で繋がりが分かる
- Jeager、ElasticAPMで観察
- Vitessは MySQLのCNCF
- Natsは メッセージングKafkaより楽
- OpenTelemetory(+Jeager
- Chaos Toolkit（でも殺すAPIがなかなかいい感じに選定できないところもある）
14-E-1：AWS障害で考えさせられた、アプリケーションインフラ構成の注意ポイント
- サーバーワークスはAWS専業
- 登壇者は元万引きGメン、今AWSに関わって２年くらい
- 20190823 東京リージョンが障害で発生したアレコレ
- 複数アベイラビリティゾーン冗長化はしていた
- サービスについては影響はほぼなかった
- 設定ミス：DBインスタンスのエンドポイントがミス
アプリを変えずにDNSの設定で宛先を変えて対処 - 設定ミス：ディスクマウントがされなかった（これは構成ミスの話）
- ここまでは早急に対応できた。逆に言うと次は重い
- プレイスメントグループ
- 気がついたこと
バックアップがとれる仕組みを考えるべきだった（書き込みのないタイミングで取得しておくなど） - 今後どうすれば良いのか
基本を大事に（ビジネス要件の確認）
重要度が低いのに過度な構成はとらないように（逆は逆）
Snapshotをとるべし - EC2へのスクリプトの置場所はEC2以外へ（同じレイヤーだと同じことが起きるかもしれない）
- 接続先にIPアドレス指定はNG。エンドポイントを指定しましょう。
- テストとしても切り替え試験の実施をすること
- 言われてみれば当たり前のことかもしれないけど、実際のところ ちゃんとやるのは別もの。私はアプリケーション側なので「やってもらっている領域」なので こういうのは知っておくだけでも大事だと改めて思った。
14-D-2：エンプラアジャイル導入の守破離
- チームの規模と何を作るのかはtradeoffになる
- 教育をしているとものが作れないというジレンマであり難しさ
- イテレーションでやっているけどスコープの決まっているものをやっているだけ
- チームがうまくできるイメージができない範囲には適用しない（トップダウンで決めるとうまくいかなくなる）
- 価値を産み出すまでのリードタイムを短くすることを優先する（成果物よりも）
- 「おとなりさんと」で集中力が切れた。運よく会話をさせていただいた方からは良い視点を得られるところはあったけれど、それを目的とするのであれば それをメインとしたワークショップでやって欲しいというのが個人的な意見。ここまでの話は面白かったし興味深く聞いていただけに非常に残念な気持ちになった。
- （以降、偏った意見になりそうなので割愛*2）
14-B-3：K8S使ってますか？リテールテック（小売・決済等）でのコンテナ活用例と「2025年の崖」克服に向けたコンテナ導入のススメ！
- RANCHERの話
- natadeCOCOの話
その場でしか接続できないWifiに繋げてサービスを提供するアプリ（QRコードで情報を渡す）
面白い仕組みだとは思ったけれど 勝手にWifiにつながることの安全性とか 気になったりもした。 - 「2025年の崖」への言及は？
14-D-4：日本にJoy,Incを創る！どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡
- 「あなたのチームは機能していますか」
- ２０１３年：３０人しかいないのにいがみ合っていた、プロジェクトは大炎上（夜中1時に顧客と打ち合わせ）
原因：経営者（自分）目先の売り上げしか見えていなかった
メンバーも何が正しいのか分からない状態 - 毎月最終金曜日に社内懇親会（１７時から１９時）マンネリ化して終わる
→目的を明確化しないと伝わらない - 月曜日、進捗会議。目的は情報共有のつもりだった。でも、月曜日からしんどい場になっただけだった。ので、社長として訴えかける場に変えた。でも、から滑り。でも続けた。徐々にメンバーの中で響く人も出てきた。そこでくじけず続けるのが大事だと学んだ
- ヴァル研究所へ見学。巻き込み方が大事。ときには強引でも その場につれていく（僕が客に謝って時間を作るから、みたいな）
- 「強いチームの作り方」ワークショップ
- ペアワーク１週間でローテーション（これはJOY.incの話）
- 語弊を恐れずに言うならば、エモい系の話だろうと思ったので一番期待していなかった*3。
たしかに「良くあるエモい系」な感じはあったけれど、なんだろう そういうのも ひっくるめて 面白かった。他人が勝手に言うことではないけれど、会社を大きくするよりも 自分の手に余る範囲でのJOY Incの実践に留めて、拡張するのではなく 他の組織へのJOY.Inc に波及、連携するのが良いように思う*4。
14-D-5：マルチクラウドに向けてNGINX活用促進する為に知っておいてほしいこと
- 直近でNode.jsでProxyをアレコレというのをやっていたので、NGINXに興味を持ったので聴講
- 「分散システムデザインパターン」を丁度 読んでいるところだったので 色々とリンクができて面白かった
- 具体的な記述例の話もあったので、スライド公開を強く期待（2020.2.15時点では
14-A-6：世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた
- JJUG 元会長の鈴木さんの最近の活動を具体的に聞ける場ということで聴講
- アイムデジタルラボ 三越の子会社（といっていいんだよね？）
- YourFIT365
- 新宿伊勢丹の婦人靴
- 立ち上げまでに２年かけた
- POは現場メンバーにする「べき」
- 今回だと「売り場」の人
- 直接やり取りをさせてもらうことが条件
- リリース日は決まっていた
- １ヶ月 ワークショップでリーンキャンバスとカスタマージャーニーをつくった
- はじめは７社が木型を提供してくれた（これは これまでの信用力）
- 「何を作りたいか」を全員が共有するために費やした
- サービスブループリント を使った
- 業務フローとシステム構成を平行して考えて検証
- 計測からリコメンドのタイムラグをどのように埋めるのかというところまで「業務設計」をした
- メンバーはアジャイルを知らない人も。２ヶ月トレーニング、開発３ヶ月
- リリース後はフィードバックとの戦い
- 接客には１名に1～２時間かかる
- 木型をベースにしたから再来客への訴求力が強く具体的である
- 立ち上げ期のあとに意図的に安定期を作り込んで振り替えりをする余裕ももうけた
- 当事者にならない人は不要＝企画部門問題（アイディアだけの人はいらない）
- 出島型：適度な自治権 が大事
距離感：既存に影響されてスピードが出ない
孤島型：既存から切り離されて過ぎて成果が出ない - デジタルで新しいことはみんなやりたいけど、組織が枠組みとなって難しいことがある＝組織を別にもうけてそこで実践する
- 統制から学習がIT部門に必要
- 結局のところ、きちんとしたモノづくりには 全員が当事者になることが大事だという当たり前といえば当たり前の話だと実感。アジャイルとかWF（といわれている かつての開発）とか、そういうことじゃないと個人的には思った。
- 泥臭く 土方仕事な感じのシステム開発かもしれないけれど、ユーザー総出で開発していた時代があって*5、そこで培った成功のプロセスがあったとして 結局 その「型」だけを採用すればイイ感じになると思って波及したんだけど、そこに本質はなくて 一番大事なのは「そんなアナログ」な部分だったというだけの気がしてならない。
14-B-7：エッジコンピューティングの時代にサーバーはどこにいくのか、自社製品をハッキングしてもらった話
- 巨大メモリサーバーで何をする？ なにかやってみたいことがあったら教えて欲しい
- データの７０％はデータセンターの外側にいる
- ハードウェアアタックが増えるでしょう（by FBI 2017）
- パンツダウン：センター監視サーバーを暴いて丸裸にすること
- サプライチェーンへのリスクが増大
- IPAの報告でも４位
- 元は防衛設備で話題になっていたところ
- 昔はメーカーの孫請がなくなることのリスクをいっていたけれど、今は部品に仕組まれたステルス攻撃のこと
- サイバーディフェンス（手島裕太）に依頼
ソフトはダメでもハードから攻撃はできるかもということで受けてくれた - ファームウェアを攻撃対象としてもらった
- 改竄されることは想定内
- アンチウィルスソフトはOS上のソフトを見るだけなのでファームウェアは対象外
- エアバスのエンジニアにホワイトハッカーがいる（GitHUBにも公開）
- 一番始めに攻撃されたのはHDDのファームウェアで、隠した領域に情報をためておいて廃棄時に回収するという仕組み
- ハードウェアにもゼロトラストの構想が必要になってきた（チェーンオブトラスト、RootOfTrust）
- 電源のファームすら危険性があるという世界（電源を止められたらセンター停止）
- HPEマイクロサーバーからマイクロサーバー新作が出る（本当は登壇日にリリースされる予定だったけど、ずれてしまった
- ハードの話は「すげー」とバカみたいな感想しか言えないけど、やっぱり「すげー」と思うし 実際「すげー」と思う。
14-F-8：家族型ロボット「LOVOT」から考えるテクノロジーの裏側とその未来
- 100億投資、100人の会社
- 人間の力を引き出すことが目標
- 愛されるよりも、愛した方が力が出るという想定（信念）
- 監視カメラか 信頼関係のあるロボットの視線か
- 存在感のある か 存在感が価値 になるか どちらかに振り切らないと難しい。中間はない（冷蔵庫に愛情を感じるとかいうのは難しい）
- LOVOTはROBOTに対するカテゴリーという思想も含めた名前
- 目指すところは ドラえもん
- 先輩は犬、猫、イルカのような存在
- 話せることと癒しは直結しない
- むしろ話せないことが、想像力で補完している自分の言葉に癒されているとも言える
- ではペットを飼えば良い？
でも実際には飼いたくても飼えないというのが実態 - でもロボットペット開発はすぐには廃れてしまったのがこれまで。
それは「飽き」が原因では？
ドーパミン（好奇心）が失くなった？Noでは？オキシトシン（愛着）が必要なのでは？ - いるのが自然な状態ということ
- 次に「ロボットネイティブ」な時代になると考えている
- 人と人のコミュニケーションの延長としての存在
- 広い意味での生物の境界はなく、生物と無生物の差がなくなると想像する
- 「Detroit: Become Human」は 林さんのいう 中間 になる話なのかなと思ったりも。そして その中間 を求めて出来るのは 都合の良い奴隷であって 愛情を共有することに葛藤のある世界（出来る人もいれば、嫌悪を感じたり、隷属を求める ことになるとか）になるのかも、と思ったりも。そのためのセーフティーとして きちんと振り切ることは大切なことなのかもしれないと思った。
さいごに
去年も参加したけど、今年の方が 私には面白かった。
なんでだろう？
