nokoのブログ

こちらは暫定のメモ置き場ですので悪しからず

Terraformについて調べたことメモ

はじめに

  • Terraformまわりについて復習したときのメモ

メモ

ディレクトリ構成案(最小構成)

.
├── README.md
└── stg01
    ├── ec2.tf
    ├── provider.tf
    └── versions.tf

ファイル例

  • ec2.tf
resource "aws_instance" "<pj>-stg01-app-01" {
  ami           = "ami-XXXXX"
  instance_type = "t2.medium"
  count = 1
  ebs_block_device {
    device_name    = "/dev/sda1"
    volume_type = "gp2"
    volume_size = 20
  }
  tags = {
    Name = "<pj>-stg01-app-01"
    Project = "<pj>"
  }
  key_name = "XXXXX-key"
  vpc_security_group_ids = ["sg-XXXXX"]
  subnet_id = "subnet-XXXXX"
}
  • provider.tf
provider "aws" {
  region  = "ap-northeast-1"
}

Terraformインストール手順(@デプロイ用マシン)

  • Terraformインストール
wget https://releases.hashicorp.com/terraform/0.13.2/terraform_0.13.2_linux_amd64.zip
unzip terraform_0.13.2_linux_amd64.zip
# PATHが通っているディレクトリにコピー
sudo cp terraform /usr/local/bin/
terraform -version
  • AWS環境情報設定
aws configure
# ~/.bashrc に記載して、 source ~/.bashrc でも可
# export AWS_ACCESS_KEY_ID=***
# export AWS_SECRET_ACCESS_KEY=***

Terraform実行手順(@デプロイ用マシン)

cd terraform/stg01
terraform init
terraform plan
terraform apply
terraform show

補足

  • リソースを破棄するコマンド
# 注意!
terraform destroy

MLOps勉強会Tokyo(Online)#1参加レポート

はじめに

メモ

MLOpsコミュニティの発足にあたり

  • DataRobot シバタさん
  • アンケート
  • 可愛そうなモデルを根絶したい
  • MLOpsは新しい分野。何が求められているのかをディスカッションしたりもしたい。
    • MLOpsに必要とされているものとは

先駆者に学ぶ MLOpsの実際

  • システム開発に置いて、データサイエンティストがやらないこと全て
    • 環境整備・成果物管理
    • 本番データでのモデル推定
    • 推論結果のシステムへの組み込み
    • 効果モニタリング
  • Walmart
    • MLプロジェクトの60-80%がプロダクションにならずに頓挫している
    • 本番化する計画は明瞭か
      • -> 企業にとって利益が出る(意味がある)システムにまで組み込み切る必要がある
  • データサイエンティスト並にデータエンジニアの求人が多い
  • Netflix
    • データの探索 2w
    • プロトタイピング 6-8w
    • 本番化 12-14w
    • リリース後のモデル更新 8w
  • MLOps NYC2019注目セッションまとめがある
  • SageMakerを使っている
  • エラーハンドリングもデータエンジニアが実装
  • とにかくデータサイエンティストの負担を軽減してあげる
  • マルチクラウドのメリット
    • AWS + GCP
    • GCPのBQ, SageMakerを使いたかった
  • コーディングフローの整備までやっているか?
    • コーディングルールとかはレビュー

DiscoveryDataScienceMeetup(DsDS)#0参加レポート

はじめに

メモ

広告文自動生成プロダクトでDataflowを導入した話

  • ダイレクトコピーの自動生成
  • Cloud Runでマイクロサービスを組んでいる
  • 分析はCompute Engineでやっている
  • pandas on GCEだとデータ量的に辛い
    • データ整形1週間とか
  • →Dataflowを使っている
  • デバッグのために、最初はローカルで行うべき。runnerオプションの切り替えだけでいい。
  • 実行環境の切り分け→Makefileとか、Dockerで包んだり
  • Dataflowでは非Pypiパッケージのインストールがかなり面倒   * 運用で使用しているマイクロサービスAPIを流用
  • Cloud Functionだとpipパッケージのインストールはできる一方、apt-get系のインストールができないんですよねCloud RunだとDockerレベルで環境を構築できるので、apt-getが必要な形態素解析パッケージをいれるためにCloud Runを採用しています!

TensorflowのモデルをGCPでサービングしてきた話

  • 予測APIの提供
  • 入力は画像andテーブル
  • なぜGCPか?→BQのため
    • クラウドの列指向DBに比べて 機能が豊富・性能が高い・使いやすい

  • AI Platform
    • GCSにモデルをおくだけで、APIを提供してくれる
  • 「結局前処理サーバーは必要だった」
  • AI Platform Custom Prediction Routine
    • ツラミ多し
    • モデルの容量制限とか
    • 廃止が決まっている
  • →結局GKE
  • 現時点だと saved model と custom prediction routine 共に Pytorch は選べないようです!

SageMakerで試行錯誤する推論パイプライン

  • 歴史
    • 最初は生EC2だった
      • ステップが密結合になりがち、一番リソースを食う処理に合わせてインスタンス選択、ライブラリバージョンが固定し辛い(1枚のpythonファイルなので)
    • →SageMaker Batch TransforをAirflowからキック
      • AirflowはECS上に自前→結構辛い
    • →Batch Transfor
      • バッチと言いつつ…。
    • →Processingを使うように
    • AWS Batchを使っていいのでは?
    • →training jobで推論までやっちゃう。スポットインスタンスのため。
      • モデルの推論も
  • SageMakerは、今までベタ書きだったコードを書き換えないといけない
  • SageMakerのlocalモードはまだできないことがある *スポットインスタンスのために、airflowは東京リージョンなのにクロスリージョンでus-east-1を
  • リトライはairflowで実装
  • 一応awsのstep functionsも検討に上がりましたが、当時はあまり使いやすそうじゃなかったのでほぼ迷わずairflow

Cloud Composerで組む機械学習パイプライン

  • CloudComposerで前処理からデプロイまで
  • クラスタ管理やログ管理がマネージド
  • GKE Pod Operator
    • Composerとは別のクラスタのPod
    • 基本方針は、全部これで(pythonとかBQやらない)
      • pythonは環境汚染。Airflow自体との競合
  • MLのリポジトリとパイプラインのリポジトリは別
    • masterにマージされたら、CircleCIでビルド、更新

検索システムのMLRモデル更新の自動化

  • Solrのメンテナンス
  • 機械学習モデルのCI/CD
  • 元々はオブジェクトストレージに置いていたが、GitLFSでおけるようになった
  • モデルのバリデーション
  • 今後は、ベンチマーク、A/Bテスト、モデル選択も自動化したい
  • Cloud ComposerにてGKEPodOperatorで全て行うのであればArgoを使ってもよいのかなと感じたのですが

  • 実験でArgoベースのKubeflow Pipelineを使っていますね。 比較すると、Airflowはやや成熟してきており色々と高機能で安定感がある

  • 一方でkubeflow pipelineは我々が検討していた段階では色々と足りない機能(失敗したrunを途中から実行など)があり、鋭意開発中感があったので本番運用に使うのは怖かったです。

  • 素のargoは使ったことはないのですが、今だとGCPでkubeflowベースのAI Platform Pipelinesも出ています

全社共通レコメンドプラットフォームへのKubernetes/Airflow導入

  • オンプレk8s
  • ジョブ管理はAirflow
  • トラフィックは10k req/s
  • Pod operator
  • なぜAirflow
  • 特徴量管理
    • BQ?
  • 実験管理
    • Kedro + MLflow tracking
    • Jupyterの相性がいい
    • kedroはドキュメントが丁寧・使いやすさなどがいい点としてあげられますね。GUIの点では定常実行を考えるとAirflowがいいですが、実験の上では十分かなと。

スクラム開発でやっていること

はじめに

スクラム開発とは

アジャイル開発のやり方の一つ
「事前に全てを正確に予測し、計画することはできない」ということが前提となるプロジェクトにおいて、
・おおよその全体像はちゃんと明らかにしつつ、
・優先度(重要度が高い、リスクが高い)を常に整理しておいて、
・もちろん直近の作業は詳細化して取り組みつつ、
・こまめに期間を区切って継続的な関係者のフィードバックを得ながら計画を修正していくことで、
要求の分析や設計などに必要以上の時間をかけないように進めていく。

やっていること

1. 『プロダクトバックログ』のベース作成(by PO)@PJのはじめ

  • やること
    • 実現したい要求をリストにして並び替える
    • ストーリー/デモ手順(完了要件)/見積もり/スプリント
      • 見積もり/スプリントについては「スプリント計画ミーティング」にて記載する
  • ポイント
    • 優先度順をきっちり決めておく

2. 「スプリント計画ミーティング」(by PO/SM/Devチーム)@スプリントのはじめ

  • やること
    • 『プロダクトバックログ』を見ながら、次のスプリントで実施する項目を選択する
    • タスクに分解+見積もり+アサインする
    • -> スプリントバックログ(Issue)に
  • ポイント
    • 見積もり工数はフィボナッチ数で(不確実性を吸収)

3. デイリースクラム(by SM/Devチーム)@毎日

  • やることとポイント
# 目的
* スプリントのゴールを達成できるか検査する
* 残作業の追跡

# アジェンダ
* PJ概況
* 前回のデイリースクラムからやっていたこと
* 次回のデイリースクラムまでにやること
* 問題点

# 備考
* 15分厳守。問題点の話し合いは別途枠を設ける。
* Issueをメンテする。
* 「他の人に共有すべきこと」に重点を置く。

4. 開発(by Devチーム)@毎日

5. スプリントレビュー(by PO/Devチーム)@随時

  • やること
    • デモを実施し、完了要件を満たしているか確認する

6. スプリントレトロスペクティブ(by SM/Devチーム)@スプリントのおわり

  • やること
    • 振り返り
      • 予定と実績
      • 予定と実績の乖離を元に、KPT振り返り
  • ポイント
    • 次のスプリントをよりよく進めるための振り返り

補足

ロール

  • PO(プロダクトオーナー)
  • SM(スクラムオーナー)
    • 開発プロセスが上手く回るようにする
    • 妨害を排除し、支援と奉仕をする
  • Devチーム(開発チーム)
    • リリース判断可能なプロダクトを作る

GitHubActionsについて調べたことメモ

はじめに

  • GitHubActionsまわりについて復習したときのメモ

メモ

ファイル例

  • .github/workflows/action.yml
name: ci # ワークフロー名

on: [push] # リポジトリへのpush時にこのワークフローを実行するよう指定

jobs:
  build-image: # ジョブの名前(ワークフローの中の一つのジョブ)
    runs-on: ubuntu-latest # Ubuntuの最新版環境内で処理を実行することを指定
    steps: # ここで実行する処理やコマンドを指定する
    - uses: actions/checkout@main # リポジトリからのチェックアウトを行う「actions/checkout」アクションを実行する
    - name: Build Docker image
      run: |
        echo "start build"
        sudo apt-get install -y wget
        wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
        cp google-chrome-stable_current_amd64.deb docker/pytorch_1_4/
        cd docker/pytorch_1_4 && docker build --tag forecast-keiba:latest . && cd -
        cd docker/pytorch_1_4 && bash run_ci.sh docker && cd -
        echo "end build"

ファイルの補足

  • on: push

    • リポジトリへのプッシュ(「push」)
    • ブランチもしくはタグの作成および削除(「create」および「delete」)
    • プルリクエストやissuesの作成(「pull_request」および「issues」)
    • issuesへのコメント投稿(「issue_comment」)
    • リポジトリのフォーク(「fork」)
    • Wikiページの作成(「gollum」)
  • 特定のブランチやタグのみを対象に指定するとき

on:
  push:
    branches:
      - master
      - foo*
  • スケジュール実行
on:
  schedule:
    - cron: '30 * * * *'
  • runs-on

    • self-hosted: ユーザーが独自に用意した実行環境
  • steps以下ではrun要素ではなく「uses」要素を指定することで、任意のActionを実行したりできる

  • パラメータを変数で指定する

    • github.sha: コミットハッシュ
  • Secrets

- name: Exports SSH private key
      run: echo "${{ secrets.SSHPrivateKey }}" > id_rsa && chmod 600 id_rsa

その他

  • Action
    • upload-artifact: 指定したファイルを「artifact」として保存する
    • cache: 生成物をキャッシュして処理を高速化する
  • プラン
    • Free: 500MB/2000分
  • マシンスペック
    • Standard_DS2_v2(仮想CPU×2、メモリ7GB、ストレージ14GB)

参考

Ansibleについて調べたことメモ

はじめに

  • Ansibleまわりについて復習したときのメモ

メモ

ディレクトリ構成案

  • 『①inventoryで対象ホストと変数を設定し、②playbookでどのロール(各機能のタスク)を実行するかを定義して、③roleでplaybookから呼び出されるロール(各機能のタスク)を定義する』をシンプルに実現するディレクトリ構成とした。
  • 変数の格納場所が分散しないよう、host_varsに寄せる(varsディレクティブ、group_vars、defaults等は使わない)
  • →本来、group_varsに寄せるべき
├── inventory                       #
│   ├── prod                         # 環境ごとに分類する
│   │   ├── hosts                   #
│   │   └── host_vars               #
│   │       ├── <system>-web01.yml  # ホストごとに作成する(変数は基本的にここにのみ格納する)
│   ├── stg01                       #
│   ├── dev01                       #
│
├── playbooks                       #
│   ├── stable                      # stable環境とdevelopment環境で分類する
│   │   ├── <system>-web01.yml      # ホストごとに作成する
│   └── development                 #
│
└── role                            #
    ├── nginx                       #
    │   ├── tasks                   #
    │   ├── handlers                #
    │   ├── templates               # ファイルを配置する
    │   └── files                   # ファイルを配置する(tar,rpm等の一時配置ファイル)

ファイル例

  • inventory/prod/hosts
######
# NODES
######
[mgmt]
mgmt-01     ansible_host=10.1.1.10

[<system>-web-blue]
<system>-web01-blue ansible_host=10.0.0.11
<system>-web02-blue ansible_host=10.0.0.12

######
# SSH connection configuration
######
[all:vars]
# SSH User
ansible_user=ubuntu
ansible_ssh_private_key_file='~/.ssh/xxx-key.pem'

######
# Python configuration
######
[all:vars]
ansible_python_interpreter=/usr/bin/python3
  • inventory/prod/hosts_vars/-web01-blue
---
###################
# nginx
###################
nginx_deploy_module_nginx: nginx.zip
  • playbooks/stable/-web01-blue.yml(サンプル1)
---
- name: playbook of <system>-web01-blue.yml
  # 変数設定(playbook内で指定)
  vars:
    ansible_hostname: <system>-web01-blue
    ansible_role_dir: /opt/ansible/roles

  # 対象ホスト指定
  hosts: "{{ ansible_hostname}}"
  become: true

  # ロール指定
  roles:
    # common
    - role: "{{ ansible_role_dir }}/hostname"
    - role: "{{ ansible_role_dir }}/env"
    - role: "{{ ansible_role_dir }}/yum"
    - role: "{{ ansible_role_dir }}/user_app-user"
    - role: "{{ ansible_role_dir }}/user_ope-user"
    - role: "{{ ansible_role_dir }}/user_view-user"
    - role: "{{ ansible_role_dir }}/dir_work"
    - role: "{{ ansible_role_dir }}/dir_script"
    - role: "{{ ansible_role_dir }}/custom_metrics"
    - role: "{{ ansible_role_dir }}/awslogs_main"
    - role: "{{ ansible_role_dir }}/awslogs_deploy"
    - role: "{{ ansible_role_dir }}/backup_log"
    - role: "{{ ansible_role_dir }}/ds_agent"
    # individual
    - role: "{{ ansible_role_dir }}/disk_mount"
    - role: "{{ ansible_role_dir }}/nginx_main"
    - role: "{{ ansible_role_dir }}/nginx_deploy"
    - role: "{{ ansible_role_dir }}/java"
    - role: "{{ ansible_role_dir }}/tomcat_main"
    - role: "{{ ansible_role_dir }}/tomcat_deploy"
    - role: "{{ ansible_role_dir }}/oracle_client"
  • playbooks/mgmt.yml(サンプル2)
---
- name: Playbook of mgmt
  hosts: mgmt
  become: true
  vars:
    _role_dir: roles/
  roles:
    - role: "{{ _role_dir }}/hostname"
  • roles/nginx_main/tasks/mai.yml(サンプル1)
---
################################################################################
# nginx セットアップ
################################################################################
- name: create nginx_rpm dir
  file:
    path={{ nginx_main_dir_module }}
    state=directory
    owner={{ nginx_main_owner }}
    group={{ nginx_main_group }}
    mode={{ nginx_main_mode }}

- name: upload nginx_rpm
  copy:
    src="nginx-{{ nginx_main_rpm_ver }}.rpm"
    dest={{ nginx_main_dir_module }}

- name: yum nginx
  yum:
    name: "{{ nginx_main_dir_module }}/nginx-{{ nginx_main_rpm_ver }}.rpm"
    state: present

- name: start nginx and set auto start
  service:
    name: nginx
    state: started
    enabled: yes
  • roles/hostname/tasks/main.yml(サンプル2)
---
- name: Manage hostname
  hostname: name={{ inventory_hostname }}

運用ルール案

  • 変数には先頭にロール名をつける
  • モジュールの置き場
    • 大きい静的モジュール: confサーバの/var/moduleに置いておいて、filesにコピーする
    • ホストごとのモジュール(*_deployロール): confサーバの/var/deploy/に置いておいて、filesにコピーする

JTF2020参加レポート

はじめに

  • JTF2020に参加させていただいたときのメモです。

JTF(July Tech Festa)とは

  • インフラエンジニアのための祭典
  • 今年のテーマは「Extend Your Engineering Life!」

メモ

凡例
☆: ToDo(追加で調べておくことなど)
⚫️: 重要(転用)ポイント

Kubernetes、第一歩のその後に ~基盤を支えるOSSとの関わり方~@太田 航平 (inductor)

  • チュートリアルから先に進めていない人向け
  • k8sの構成
  • それらがどうやって開発しているか
  • DockerはdotCloud社が公開したLXCベースのアプリケーションが始まり
  • k8sはインフラを抽象化。統一されたインターフェイス。「どのホストに〜」ではなく「メモリ2G欲しい」
  • k8sの3つの顔⚫️
  • CNCF
    • Linux FoundationとGoogleが設立
    • Kubernetes以外にも
    • コンテナ技術単体ではない
    • ベンダーの偏っているプロジェクトは受け入れない
  • SIGs
    • あらゆる決定はSIGによって行われる
    • SIGごとにチェア(代表)がいる
      • api-serverの標準化
      • テスト自動化の推進
      • ドキュメント化
  • k8sそのものがコンポーネントにわかれたマイクロサービス
  • k8sの構成⚫️
    • クラスタ
      • クラスターを構成するコンポーネントをリソースと呼ぶ
      • リソースはAPIオブジェクトで、プログラム上で管理
      • 1台以上のノードの集合と捉えることもできる
      • ノードは物理または仮装マシンと非常に近い
        • VMがあって、その上で必要なプロセスが動いている
        • コントロールプレーンとワーカー
          • コントロールプレーン
            • 司令塔、管理用ノード。元master
            • etcdは外に出すことが多い
    • (補足)kube キューベ
    • kube-api-server
      • 全てがここを通る
      • etcdに触れる唯一の存在
      • kubectl
    • contoroller Manager
    • kube-schedurler
      • cronとかとは違う
      • 新しいPodが作られたときに、どこに配置するかを決定
    • kubelet
      • ノードに1台いて、まず、ノードがいるよ、と伝える
      • 命令を受けたら、コンテナ作成司令をコンテナランタイムに送信
    • kube-proxy
      • 「どのノードでも同じように動いて欲しい」=「ネットワークを透過的に」
      • iptables
    • コンテナランタイム
  • どこで開発されているか
    • kubeで始まるものは大元のリポジトリ
    • それ以外は個別のSIG(cloud contoroller managerとか)
    • etcdは別
  • 公式のチュートリアルがある
  • 認定資格がある
  • kubernetes the hard way⚫️
  • k8sの基本構造はWebアプリケーションと同じ
  • 自動化の恩恵をフルに活用するためには両方の知見が必要
  • Don’t ask to ask
  • Land Scape, Trail Map
  • KEPで議論されている
  • 世界で二番目に大きなコミュニティ⚫️
  • Docs以外で面白そうなSIG
  • kube proxyがBGP?
    • CNIがBGPを使うことがある
  • workerがdata planeに?名称を統一。今は動いていない。
  • ☆構成全体像の図
  • k8s記事への反映(k8s構成の説明)

f:id:noko_htn:20200725143009p:plain

AKSを活用した内製教育支援プラットフォームをリリースした話@河原 慎吾

  • 経歴
  • テクノベーションセンター   * 全員が専任(他社では兼任があるある?)
    • ブランド向上、全社の技術スキル向上
  • 内製教育のメリット
    • 実業務で発生した疑問をすぐに聞ける。いざ必要になった時に。
      • 勉強会は、現場と研究組織の接点⚫️
    • 講師は現場の状況を把握することができる
  • 勉強会(イベント)の当初の課題
    • 申し込んだのを忘れるとか申請とか
  • 開発の前にデザインシステム
    • ☆表
    • ペルソナ設計大事⚫️
      • インタビューの分析結果から、共通点を抽出し人物像を当てていく
    • カスタマージャーニーマップの作成⚫️
    • プロトタイプの作成⚫️
      • Prott
    • モックアップの段階でユーザテスト
    • デザインプロセスは時間がかかる
    • ペルソナやマップをアウトプットすることで後で立ち返れることがメリット⚫️
  • なぜAKS使ったか
    • Web App for Containerでもよかった
    • 運用してみないと、k8sの良さや苦労が分からない。⚫️
  • Azure ARM Template
    • コード化にこだわりすぎない。初期セットアップを楽にする、くらい⚫️
    • もし壊れても一から作り直せる安心感
    • パスワードは、実行するときに指定
    • 公式にクイックスタートテンプレートがある⚫️
    • 頻繁に変更が入るのはマニュフェストファイルの方。こっちはあんまり。
  • 本番と検証でクラスタを分けている
    • k8sのアップデートの検証⚫️
    • ステージングは監視していない、開発環境と同居
    • 結局、開発とステージングは同ノードでnamespaceを分けて構築した⚫️
  • Nginx Ingress
    • 社内からのみアクセスするように元IPを制御
  • Let's Encrypt⚫️
    • Helm Install
  • Helm⚫️
    • yumに近い
    • cart-managerを入れたり
    • upgrade
  • アップデート⚫️
    • k8sはとにかく早い
  • HPA
    • Podの使用状況に応じて
  • ヘルスチェック
    • Podの再起動
    • Podへの通信を止める
    • 色々パラメータがある。ヘルスチェック開始までの時間とか
  • Azure Monitorで監視
    • コンテナーが落ちても自己復旧だが、クラスタ自身は監視
    • Slackに通知
    • -> 細かくログを見るときはkubectl logs, describe⚫️
  • コンテナレジストリ
  • CI/CD⚫️
    • drone
    • developブランチ→開発環境に
    • master->ステージング環境に
    • タグ→本番環境に
    • secretはWebUIから事前設定
    • コミットハッシュ値をタグに
    • デプロイはkubectl applyとかを書いていく
    • latestを使いたくない
      • 動的に変更したい
    • リリース後に不具合があった場合に、即座にリストアできるかどうかが大事
    • CI/CDはリストア駆動で設計する。劇的に生産性が上がるため、早めに作った方が良い。⚫️
  • logはAzureに転送。ESとかは使っていない。Azureのlog analitics。

f:id:noko_htn:20200725143054p:plain

人のチームでどうやって開発者をkubernetes開発に巻き込もうとしているか@大平 譲

  • Terraform Cloud, argocdでGitops⚫️
  • 人数が少ないチームこそ自動化
  • 連絡のフローを飛ばして、開発者にマニュフェストを書いて反映をしてもらっている
  • マイクロサービス
    • コンテナが増えていったときにどうするか。保守作業
    • -> 開発チームの一人にインフラ構築を任せた
  • uberとかはmicroではなくmacroくらい

Prowに学ぶKubernetesのCI環境@bells17

Kubernetesを用いた車両用クラスタ管理とvehicle service mesh@Yong Jun Kai / @天地 知也(tomoyamachi)

  • 車向けの注意点
    • linuxと限らない
    • NWの切断
  • Misaki
    • k8sベース
    • 組み込みを学ぶ必要がない
    • NW瞬断問題に対応
    • まだプロトタイプ
  • ECU
  • 仕組み
    • Cloudにmasterがいて、車にnode
    • VPNで接続
    • 車のスペックによって載せるコンテナ(機能)は変える
  • Helmでデプロイを管理
  • サービスメッシュとは
    • ネットワークレイヤの管理
    • ロードバランシング、デプロイ、ポリシーコントロール、モニタリング、TLS接続の管理
    • Istioなどが有名
    • 各コンテナにproxyを置く+コントロールプレーンを介してやりとりする
    • ☆サービスメッシュのメリットの図
    • ccc = cross cutting concerns
    • サービス開発者が、ネットワークを考慮しなくていい
    • configはproxyのコードに入れれば良い
  • control planeとdata plane
  • ローカルのDNSマスク

f:id:noko_htn:20200725143133p:plain

”ワタシハ セフ チョットデキル" への道

  • Ceph
  • マジイケ頭足類
  • SPOFなし
  • オブジェクトストレージもファイルシステムもブロックデバイス
  • 勝手にリバランスしたりスクラブしたり。運用負担を減らしてくれる。
  • APIが色々
  • 専用ハードは必要なし
  • ☆かっこいい公式動画がある
  • 歴史
    • 2003年(S3は2006年)
    • 原理的な部分は当初から洗練されている
  • だいたい1年に1回のメジャーリリース
    • ライフサイクルは2年
  • アーキテクチャ
    • RADOS(れいどす)
      • ベースとなる仕組み
      • データのアルゴリズムはCRUSHアルゴリズム
        • 誰でも計算できる=単一障害点をなくす
      • MON/MGR/OSD
      • MON
        • クラスターの状態を監視
        • クラスターマップを作成/更新/配布
        • クライアントも、このマップを利用すれば、直接OSDアクセスが可能
      • MGR
        • MONとセットで動く
        • 外部へ監視情報を提供したりする。ダッシュボードの機能も提供する
      • OSD
        • データの出し入れをする
        • OSDは互いに死活監視している。異常があればMONに報告する。
  • CRUSHアルゴリズムとは
    • オブジェクトをどのOSDに配置するか決定するアルゴリズム
    • メタデータを中央集約するサーバが不要⚫️
    • Pool=オブジェクトを保存するための論理的な領域
    • Erasure RAID5/6 パリティ 速度はかかる。レプリカの方が早い
  • CRUSH Map & Rule
    • 物理配置トポロジーを定義
    • フロアを分けるとかラックを分けるとか
    • 物理配置を考慮してデータを配置してくれるように
    • poolごとに設定。poolAはhostレベルの分散でいい、rackレベルの分散でいい、roomレベルの分散までする、など
  • Placement Group
    • clientは、どのPGにデータを預けるかだけ
    • weightを考慮(人が計算するわけではない)
  • librados
    • 各種言語向け
  • rados gateway
    • S3互換
  • RBD
  • ファイルシステムメタデータはMDSが管理
  • NFS Exportも可能
  • MDS
  • コンテナ仮してコンテナオーケストレーション基盤上で管理しやすい
    • Rook
  • 分散システムなので、速いネットワークは正義

ツイートしたこと

kubernetes the hard way
Kubernetesクラスタを立ち上げるための必要な各タスクを確実に理解するための、長い道のり
https://springmt.github.io/kubernetes-the-hard-way-ja/kubernetes_the_hard_way/#0
#JTF2020 #JTF2020D
CI/CDはリストア駆動で設計する。劇的に生産性が上がるため、早めに作った方が良い。
Droneを利用。latestタグを使わないために動的に変更するようゴニョゴニョ工夫。
#JTF2020 #JTF2020D

直近業務で活かしたいこと

  • CI/CD
    • Ansibleと、k8s(マニュフェスト)それぞれ
    • 定期的にAnsible実行してデグレチェック
    • GitOpsも検討
  • k8sの環境設計
    • NameSpaceを分けるかどうか
    • 検証用の環境
  • Helmの活用検討
  • デザインシステムの導入
    • ペルソナ設計、カスタマージャーニーマップ作成、ユーザヒアリング
  • アップデート対応の準備
    • k8s
      • k8sはとにかく早い(masterもworkerも)
    • Docker
    • ドライバ
    • cuda
  • ジョブの並列実行対応
  • 障害時切り分けの手順整備
    • kubectl logs, describe
  • コンテナレジストリ脆弱性スキャンを実施