Infra Study Meetup #7 memo

セミナー情報

セッション

基調講演「エッジ・フォグコンピューティングの成り立ちとネットワークインフラのこれから」

  • 資料
  • さくらインターネットの方
  • エッジコンピューティング
  • ネットワーク形態
    • ３パターン：2000年代
    • IoT：2010年代
      • 「遅い」と言う問題発生
      • サーバを網のところに持ってくることをエッジコンピューティング
  • クラウド型
    • MEC領域に伸ばしてきている
    • AWS, Azure, Anthos for Telecom
    • 国内：KDDI はAWS
  • AWS Outposts
    • AWS ラックを自営網におけるもの（IIC型のエッジ相当）
      • 実際にサービス化しているのは聞いていない
      • さくらとしては驚異
  • IICの動向
    • あまり動きはよくない
    • OpenFog 合併後あまり変わっていなかった
    • 10/20 にプレスが出た
      • ゆるゆると進んでいる（クラウドベンダーに比べると遅々）
  • 広がるエッジ
    • Micro-DC
    • 車自体がエッジノード
    • エッジAI（エンドデバイスが頑張っている：スマホ）
    • センサー収容していくもの（データを束ねたりするもの）
    • 線引きが曖昧となってきている
    • どのようなタイプなのかを整理して話をするようにした方がいい
  • 想定ユースケース
    • e-Sports
    • Connected Car
    • エッジで画像処理
    • エッジAI（非常に盛ん）流行っている
      • 網にないエッジ
  • クラウド側は進化してきている
  • 端末側に課題あり
    • サーバや端末の移動への対応が非常に難しい
    • すっきりした解決策がない（検討中）
    • 監視とかどうやるのかとか
    • 業界を巻き込んだ検討が必要
  • アクセス網の改革を進めていく必要がある
    • Webサーバ型ではなく、パブサブとかになるとか
  • 資料には「フォグ」の意味合い説明がある
  • Q&A
    • 単にエッジをおきました、だけではアーキ変更にはならない
      • サイロ型のエッジ構成となるかもしれない
    • ５Gになると、携帯網から直接外に出ることができる（インターネット網に行かなくてもいい）

LT1「IoT制御システムのフォグコンピューティング一歩手前の現状」

  • [資料]
  • 近い将来に突き当たる壁
    • すべてのデータをオンラインで処理することは不可能になる
      • スピード面、費用面での限界
    • セキュリティの関係から、閉域以外にデータが上げられない（上げたくない）
      • 全データをクラウドには上げない前提の許容 f:id:san-tak:20201024170737p:plain f:id:san-tak:20201024170756p:plain

LT2「猫でもわかる KubeEdge」

  • 資料
  • KubeEdge と言うツールの詳細な動作説明

LT3「コネクティッドカーを支えるエッジコンピューティングへの期待と動向」

  • 資料
  • トヨタの方
  • コネックティッドカー　ネットワークにつながっている車
  • 車の部品≒IoT
  • 多くのデータの負荷分散する方式のご説明
  • End2End のユースケース例
  • AECC と言う国産標準化団体
  • エッジのなかでk8sが出てくる
    • コンテナ管理できるのが、これしかないと言う選択肢

感想

  • 本セミナーを見ることでぼんやりとしていたフォグとエッジ、MECと言う用語の意味がわかってくる
  • 自動車会社も今後はコンピューティング会社になってきていることもわかる

20201017 Code for Japan Summit 2020 memo

cfjsummit

セッション情報

10/17 セッション

キーノート

  • 唐鳳さん
    • 台湾IT大臣
  • COVID-19 台湾モデル
    • 公平な配分
    • 強権的な対応をしなかった（裏社会化させたくない）
    • ランタン！
    • 「日増風彩」
    • メッセージ：市民をもっと信頼しよう

公開ディスカッション：シビックテックコミュニティがサービスを提供するなら 〜「まいにちに.おきなわ」の場合〜

まちづくりとナラティブ

  • https://summit2020.code4japan.org/program/?id=136
  • まちづくりは色々なプレイヤが関わる
  • 「ナラティブ」
    • 共感を呼び起こす
    • プロファイリングする（ペルソナ）
      • 暗黙知を引き出している（ユーザに対する共感を呼び起こす）
    • ビジョンを描く
      • ストーリボード
  • 地方のデジタル化
  • 職人はデジタルでない業務が重要
    • Miroを使った（ホワイトボードツール）
  • 疎外感、
  • 神社
    • よく分からないが経験的に（みな）理解している
    • 感覚的知覚によるナラティブ
    • ツールは思考を変えてしまう。FacebookとInstagram では同じ写真でも異なって見える
    • 情報はネットワークが生み出す
  • ナラティブの可視化できるか
    • （コミュニティ間とか）跨いでいる人を見つけ出すといい
  • オープンダイアログ
  • サイレントマジョリティのナラティブ
  • シビックテックの人たちの言葉は特殊
    • 受け入れられない（９９％は）
  • ナラティブと言う言葉でこんなに広がる！

グローバルスタートアップ拠点都市名古屋！本気で先進技術実証に取り込むHatch Technologyとはなにか！！

シニア2.0！シニアがプログラミングで実現する未来

10/18 セッション

キーノート

  • シビックテックが未来の鍵
  • データは共有財となった（重要）
    • 使われ方も含めて声を上げていくことが大事
  • どうやってアウトリーチしていくか
    • 課題
      • 横文字が多い
      • 壁が高い
      • ツールを使ってもらえない
    • どうするか
      • 教育：ICTを日常に使っていなかった（まずはPCを配らなければいけなかった）
      • モチベーションの問題（高齢化）
    • マイナと銀行口座紐付け
      • そのことしか示していない
      • 何ができるのかを示さないと
  • 企業だけだと、利益だけを考えてしまう
  • 省庁間の壁を崩す必要あり
    • 多様な視点が必要
    • これを共有し続ける必要がある
  • 仕事が細分化させ過ぎている（日本）
    • 自分の仕事が結果、何に役立っているのかわかっていない人が多い
    • 今までの仕組みをデジタル化するのではなく、デジタルに合わせた仕組みに再設計することが必要
  • シビックテック
    • 課題から体験価値へ持って行っていた
    • データの繋げ方、対極的に考える。視野を広げることが大事
  • Take OUT のプロジェクトが行われた
    • 繋がりができてきた
  • 地域では
    • 「都市化」が進んでいた（before COVID-19）
    • 転換点かも
    • 未来の人材
      • 問いを考えていく
      • 生きた学習をしていく
  • 期待は
    • 社会の豊さをみんなで築き上げていく
    • 国主体ではない
    • 多層型になるのではないのか
    • 硬直した民主主義を解きほぐすのではないのか
    • 「志」大事

霞が関の非日常

経済産業省デジタルサービス開発プレイブック

CodeForGiin（議員）スタートです。何のブリゲードなの？(副題）あなたの知らない議員の世界！

  • https://summit2020.code4japan.org/program/?id=143
  • 若い議員が、慣例を変えていく原動力になっていることを感じる
    • 出席者は、「一般的な議員ではない」。こう言う人が選ばれるように
    • 前例がない、と言うのがこれまで
      • プロトタイプを見せてあげると、意外と進むことがある
    • 心からの提案をして欲しい、と

東京都新型コロナ対策サイトのアクセシビリティ改善を語る

所感等

  • シビックテックと言うと、東京都感染者サイトを開発で一躍有名になった、くらいの知識でサミット参加
  • Code for Japan と言う活動について、このサミットで外観が掴めた
    • 様々な方々が社会をよくするために協力しあって活動している
    • 行政の取り組みについて、大きく進めているところと何もしていないところの差が大きいのだろう
    • 経産省の推進も従来のベンダー丸投げではなく、自ら進めると言う方向を感じる（CIO補佐官など）
  • COVID-19により、（IT技術の急速な導入で）良くも悪くも地方と都市の障壁が本当に無くなっていくと言う動きが強く感じられる
  • 行政も一般企業も個人も日々の学習や展開が重要

その他

Waypoint のGetting Started を試してみた

Hashicorp waypoint getting started

Waypoint

Waypoint のGetting Started を試す

動作確認した環境について

waypoint のインストール

CentOS 8 上に構築していきます。

  • waypoint バイナリをインストールします
$ sudo yum install -y yum-utils
$ sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
$ sudo yum -y install waypoint
  • はじめにwaypoint Dockerコンテナをpull します
$ sudo docker pull hashicorp/waypoint:latest
latest: Pulling from hashicorp/waypoint
df20fa9351a1: Pull complete 
464c4c2e60be: Pull complete 
802d9b65569c: Pull complete 
Digest: sha256:689cae07ac8836ceba1f49c0c36ef57b27ebf61d36009bc309d2198e7825beb9
Status: Downloaded newer image for hashicorp/waypoint:latest
docker.io/hashicorp/waypoint:latest
  • waypoint サーバを立ち上げます
$ sudo waypoint install --platform=docker -accept-tos
✓ Server container started
Waypoint server successfully installed and configured!

The CLI has been configured to connect to the server automatically. This
connection information is saved in the CLI context named "install-1602898408".
Use the "waypoint context" CLI to manage CLI contexts.

The server has been configured to advertise the following address for
entrypoint communications. This must be a reachable address for all your
deployments. If this is incorrect, manually set it using the CLI command
"waypoint server config-set".

Advertise Address: waypoint-server:9701
HTTP UI Address: https://localhost:9702
  • UI Address をブラウザで開くと、Waypoint の管理画面が表示されます
    • 本検証環境では、VirtualBox のホストマシンからアクセスしたため、VMのアドレスを指定して確認しています
      • https://192.168.56.110:9702
    • ログイン時のToken は以下で取得します
$ sudo waypoint token new
  • f:id:san-tak:20201017142013p:plain

サンプルアプリケーションのビルド、デプロイ、リリースの実施

  • サンプルアプリケーションのダウンロード
$ git clone https://github.com/hashicorp/waypoint-examples.git
  • waypoint を実行するディレクトリへ移動
    • waypoint.hcl が必要です
$ cd waypoint-examples/docker/nodejs
$ ls
Procfile  README.md  data.db  index.js  package.json  public  views  waypoint.hcl
  • waypoint を使ってビルド、デプロイ、リリースの実施
$ sudo waypoint up

» Building...
Creating new buildpack-based image using builder: heroku/buildpacks:18
✓ Creating pack client
✓ Building image
✓ Injecting entrypoint binary to image

» Deploying...
✓ Setting up waypoint network
✓ Starting container
⠧ App deployed as container: example-nodejs-01EMT3TBE2G1CRMCDCYQ5KRG50

» Releasing...

The deploy was successful! A Waypoint deployment URL is shown below. This
can be used internally to check your deployment and is not meant for external
traffic. You can manage this hostname using "waypoint hostname."

           URL: https://secretly-amazing-marmot.waypoint.run
Deployment URL: https://secretly-amazing-marmot--v1.waypoint.run

アプリケーションの動作確認

アプリケーションのアップデート

  • docker/nodejs/views/pages/index.ejs の18行目を適宜変更
    • 例
      • 変更前：<h1>This Node.js app was deployed with Waypoint.</h1>
      • 変更後：<h1>This Node.js app was deployed with Waypoint. Testing updated. </h1>
$ sudo waypoint up
» Building...
Creating new buildpack-based image using builder: heroku/buildpacks:18
✓ Creating pack client
✓ Building image
✓ Injecting entrypoint binary to image

Generated new Docker image: example-nodejs:latest

» Deploying...
✓ Setting up waypoint network
✓ Starting container
⠏ App deployed as container: example-nodejs-01EMT4GPYEWSV43VNTMC8QXAVY

» Releasing...

The deploy was successful! A Waypoint deployment URL is shown below. This
can be used internally to check your deployment and is not meant for external
traffic. You can manage this hostname using "waypoint hostname."

           URL: https://secretly-amazing-marmot.waypoint.run
Deployment URL: https://secretly-amazing-marmot--v2.waypoint.run

デプロイ後のWaypoint UI での確認

アプリケーションの削除

  • 削除前の確認
$ sudo docker ps -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS                              NAMES
18532d017dda        example-nodejs:latest       "/waypoint-entrypoin…"   6 minutes ago       Up 6 minutes        0.0.0.0:32769->3000/tcp            example-nodejs-01EMT4GPYEWSV43VNTMC8QXAVY
d4903838094a        4a1737d832be                "/waypoint-entrypoin…"   19 minutes ago      Up 19 minutes       0.0.0.0:32768->3000/tcp            example-nodejs-01EMT3TBE2G1CRMCDCYQ5KRG50
8a788375f6de        hashicorp/waypoint:latest   "/usr/bin/waypoint s…"   32 minutes ago      Up 32 minutes       0.0.0.0:9701-9702->9701-9702/tcp   waypoint-server
  • アプリケーションの削除
$ sudo waypoint destroy

» Destroying releases...

» Destroying deployments...
Destroy successful!
  • 削除後の確認
$ sudo docker ps -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS                              NAMES
8a788375f6de        hashicorp/waypoint:latest   "/usr/bin/waypoint s…"   33 minutes ago      Up 33 minutes       0.0.0.0:9701-9702->9701-9702/tcp   waypoint-server

備考

  • 2019年の Mitchell Hashimoto in Tokyo! HashiCorp Meetup で新しい製品を開発中、とMitchell が話されていた。それがこのwaypoint だったのだろうか
  • まだ、このツールを深く見れていないが、アプリケーション開発者に対して様々な構築・運用する手間を取らせない、と言う方向性は正しいと思う
  • Waypointとは何か

20201005 Tech-on MeetUp Online#03 memo

セミナー情報

Google が目指すマルチクラウドの姿

ZOZOTOWNのクラウド活用戦略

20200928 INEVITABLE ja night 12 memo

セッション情報

説明引用

インターネットの次にくるもの
INEVITABLE ja night
Google Cloud に代表されるクラウド技術の進化が引き起こすその先の世界を、機械学習、VR / AR、IoT などの領域で活躍されているスタートアップの方々と一緒に議論するイベント「INEVITABLE ja night」。
第 12 回目となる今回は、「行政サービスにおける、Gov Tech / Civic Tech の不可避な流れ」がテーマです。新型コロナウイルス感染症の拡大をきっかけに、行政サービスのデジタル化への要望がかつてないほどに高まっている中、Gov Tech / Civic Tech 双方のアプローチでの対応が加速しています。 今回の INEVITABLE ja night では、それぞれの分野で先頭を走る方にお越しいただき、行政サービスのデジタル化を取り巻く課題や、見えてきた今後の潮流についてお話いただきます。
現状と課題、クラウド技術を使った国内外での事例についても触れながら、このイベントに関わる皆様がお互いに刺激し合うことで、有意義な発見と共有の場にしていくことを目指しています。
ハッシュタグ : #inevitableja
2020年9月28日 21:00  - 22:20  JST

対談

  • コロナ化で行政サービスが進んでいるのか
    • 後付けシステムは一気に進んだ
    • 本丸システムは変わっていない
  • 電子化
    • 台湾：保険証にIDチップが入っている
  • 日本はアナログ行政のクオリティが高いゆえに、デジタル化が進まない
    • テクノロジの問題ではなく、構造上の問題
    • 縦割り問題、自治体バラバラ（横割り）、個人情報の扱いがバラバラ
  • デジタル庁、タイミングいい
    • SHIFT止まり
    • AI化が本当は必要
  • 今はLIFT
    • RPA が花盛り
    • 現場で回っていた
  • Civic Tech
    • アプローチ
    • オープンソース化（税金で作っているのだから）
    • PM が重要（公助、共助）
    • タダで作ってくれるのものではない
    • ベンダーでも同じ考えを提供できるはず
    • 単年度会計はそれで問題
  • 大手ベンダーはできない理由を言ってくる
  • キーテクノロジ
    • じこび
  • イニシアティブ
  • IT 音痴

その他

20200924 OpenShift.Run Summer #10 参加メモ

OpenShift

OpenShift.Run Summer #10 参加メモ

セッションメモ

個人的な備忘録です

Kubernetesと連携するアプリケーション開発手法

memo

  • 青山さんご講演
  • GPU as a Srevice での工夫点をご説明
    • ML 環境をサービス提供
    • ストレージなどもすべてk8sマニフェストで提供
    • NamespaceごとにRBAC 定義
  • Kontest OPA 含めテストができる
    • CNDT資料
      • Kubenetes のCI/CD エコシステム鳥瞰図を示してくれている
  • Kubenetes Controller
    • 任意のスキーマでCustomResource を監視して処理追加できる
    • 課金が必要な場合：cronでの定期実行でチェック
  • Admission Webhook

所感など

  • すべてのマニフェストで管理していく、という展開はありだと思う
    • Admission Webhook は理解していきたい技術要素

エンプラに Kubernetes を導入してみて分かった4つの Lessons Learned

memo

  • 資料
  • IBM のSEの方による、金融系システムへのk8s適用の学び
  • 段階的なクラウドネイティブが必要(P6)
    • ただ「既成事実化」も意味あり
  • Lesson1（コストとスケール）
    • k8s を動かすだけでも多くのリソースが必要
    • スケーラビリティのあるオンプレ環境構築は難易度が高い
  • Lesson2（現行運用との兼ね合い）
    • 監視に関しては、多くのすり合わせが必要
    • オンプレはインターネット接続ができない、というのはよくある話でみんな苦労している
  • Lesson3 モダナイゼーションへの道
    • The Twelve-Factor App を指標に
    • Single Source of Truth
    • 本当に必要なCI/CD を設計する
  • Lesson4　チーム
    • k8s, OpenShift のバージョンアップへの対応

所感

  • エンプラ系でk8sを運用するための工夫や苦労がよくわかる内容
  • DAY2運用、保守の大変さはこれから、ということで人のスケールではない仕組みが必要となってきている

Kubernetes で実践するクラウドネイティブ DevOps （オブザーバビリティ編）

memo

  • 資料
  • クラウドネイティブAPPは常にどこかが壊れている、前提で
  • (P19) メトリクスは「動作している/していない」という単純な判断を超えて監視の新たな次元を切り開く（★）
    • 「なぜか」をあきらかにする
    • 「問題の予測」に役立つ
    • APPを内部から監視する

所感

  • P41 まとめはGood!。この整理は引用していきたい（★）
    • クラウドネイティブで重要な役割を果たすのが「メトリクス」
    • Promethus が事実上の標準

Kubernetes クラスタのログ分析と可視化で知っておくべきこと～Elastic Stackの特性と注意点～

memo

  • 資料
  • ログ管理の概要を説明されている

所感

  • ログ管理はまた到達していない領域なので、あとから読み直せるようにBookMark!

OpenShift cluster-monitoringで困ったこと学んだこと

memo

  • 資料
  • OpenShift, Promethus について順を追って理解した経緯がわかりやすい
  • P33以降、実際の運用での工夫や苦労があり参考になる

(LT) コンテナレジストリサーバーにコンテナ以外を格納する

  • 資料
  • OCI Artifacts ?
    • 今後の動向をWatch しておく必要がありそう
  • クラウドネイティブだからおこるCI/CDでのトラブルの説明（★★）

(LT) Upgrade 4.4 to 4.5 with OTA その裏側

20200908 Cloud Native Days Tokyo 2020 メモ

Qrunchからの移行（ログ） CNDT2020

セミナー情報

気になったセッション

モノリスからクラウドネイティブへ - 設計思想の違いを知り乗り越える

  • 資料
  • サイボウズ
  • クラウドネイティブ化までのジャーニーを説明
  • k8s != クラウドネイティブ
    • 「どう使うか」が重要
  • 自動テストの重要性

基礎から学ぶ！アプリケーション開発者のためのKubernetes入門

  • 資料
  • k8s にはオーケストレータはいない
  • K8s を使う前に考えるべきこと、が役に立つ
    • マイクロサービスであってもk8s はいらないかも

MackerelにおけるCloud Nativeへの取り組みとチームに与えた変化

Kubernetes 水平オートスケーリング 実践入門

  • 資料
  • オートスケーリング設計が必要
    • 負荷の変動傾向を調べることが始める

ZOZOにおけるID基盤のk8sへのリプレイスとセキュリティの取り組み

攻撃しながら考えるKubernetesのセキュリティ

  • 資料
  • セキュリティを考えずにk8s を使っている
  • ベストプラクティスを参考に

Amebaアフィリエイト基盤のGKEアーキテクチャとマイクロサービス

  • 資料
  • k8s を選択した理由
  • GKE を選択した理由
  • gRPC のバランシング
  • 監視はDatadog 使用
    • Stats はPrometheus Exporter へ変更中
  • マイクロサービスを採用した理由
  • CIOps を採用

Cloud Native Onboarding ~実践で身につけるモダンインフラの基礎~

  • 資料
  • メンターとメンティーの関わりのきっかけとなる

VictoriaMetrics+Prometheusで構築する複数Kubernetesの監視基盤

メルペイにおけるマイクロサービス運用の苦労と改善

  • 資料
  • GCP でマイクロサービスを運用
  • 組織面も明確化
  • マイクロサービス の運用は大変
  • 留意点
    • SLOの設定
    • Observability
  • マイクロサービス開発運用での具体的な課題事例あり（★）

最新テクノロジーを導入・運用していく組織設計

  • コロプラ：ゲーム会社
  • 2012前はオンプレ、2016以降はGCP
  • マネージドサービスは使っていない
  • 課題
    • トラフィックのピークタイミングの変化
    • インフラのオペレーションコスト増加
    • コードのメンテナンス性低下
  • Cloud Spanner
    • 課題解決のキー
  • 属人性を排除する組織体制

Cloud Native環境におけるエンタープライズシステムに対する高可用性実現への取り組み

  • NTT-Com
  • クラウドネィティブ化が進んでいる（Flexble InterConnect）
  • パブリッククラウド業者向け
  • リフト＆シフトモチベーション
    • 開発アジリティ
    • スケーラビリティ
    • 可観測性
    • オペレーションコストの削減
  • ビジネスモデルが変わってきている
  • リフト＆シフトの課題
    • APのコンテナライズ化
    • スケールできるようにシングルプロセス化
    • シグナルハンドリング（コンテナ）Pod終了時の動作
    • LB組み入れと自動回復の変更
    • 自動でミドルウェアのUPDATEはエンタプライズシステムでは怖い
    • 通信事業者：MTBF を重視していた
  • 高可用性への取り組み
    • クラウドネイティブとは
      • 可観測性を高めた
      • カオスエンジニアリング採用：Fault Injectionを実施
    • MTTRを短くするために、疑似故障を起こしてみた
      • メトリクスベースで確認
    • Dockerfile 見ていても、シグナルが伝播することはわからない
    • Graceful Shutdown
      • k8s を押し付けてはいけない（SREとして）
    • ミドルウェア故障
      • Liveness Probe / Pod までDelete した
    • GCP / k8s LB
      • 502 が返ることがある
      • GCP がどのように動いているのかを理解する必要があった

Kubernetes-native な管理をおこなう CI/CD 2020

Dapr × Kubernetes ではじめるポータブルなマイクロサービス

  • 資料
  • マイクロサービスへの道筋
    • マイクロサービス化を目指す判断基準
    • そのステップ
    • 実行環境の変化とポータビリティ
  • マイクロサービスにあった組織編成
  • Dapr の採用

KubernetesにSecurityをねじこむ！ - マイクロサービス基盤における多層防御システム構築の軌跡

  • 資料
  • 金融システムを題材にセキュリティリスクの説明あり

いくつかの商用コンテナセキュリティサービスをNIST SP800-190ベースに、独自観点を追加して検証した話

  • 資料
  • コンテナ利用でのセキュリティ課題
  • Security by Design
  • 開発だけでなく運用でも、従来とは異なるアプローチ必要
  • 詳細な手法が記載された貴重な資料

以上