kuzira_diver

Professional Cloud Architectに合格！ Professional Cloud Architectに合格しました。勉強方法などを振り返りたいと思います。 　 GCP Professional Cloud Architectとは？

GDG DevFest Osaka 2019 日時：2019年12月08日　10:30～ #DevFest19 #gdgosaka #Japan #Osaka #Google TensorFlow Lite, Edge TPU and Auto ML(Google 佐藤 様) 機械学習のお話。 なんでML？→新しいプログラミング。AIはアプリケーションの１つ。 IoT膨大な情報。いちいちコーディングしていられない。MLは『なんとなく』を実現してくれる。新しい手段。 とにかく情報を集め、そこからパターンを作り出すのがML。自動プログラミング。精度100％はでないが、強力（近似までもっていける）。 最近は小さいコンピュータにもMLが乗っている。スマホ、ラズパイ等。 エッジ側にMLがあると レイテンシが少ない。 ネットに繋がってなくても動く データがローカルで完結する 必要なデータのみを圧縮しクラウドへ  モバイル用に『TensorFlow Lite』登場。  Firebase ML KiTにも『TensorFlow Lite』含まれている。 CPUクロックの向上が飽和状態、専用プロセッサに特化し始めている。 ランタイムで専用プロセッサとの間を取り持つ モデルを作り、コンバーターで最適化 Dance Like（スマホアプリ）　セグメイテーション　体の部位を特定して判断 Smart Mirror　鏡にカメラを埋め込みリアルタイムで画像を認識変換 Edge TPU Googleが１から開発したCPU。 Efficientnet Googleの最も早いニューラルネットワーク 60fpsで物体を判断検知。工場の外観検査（京セラ）で使っている Coral　Googleのハードウェアプラットフォームで買えます。 データサイエンティストが少ない⇒半自動化がクラウド側のAutoML AutoML Vision（京セラの事例：工場の製品に傷）独自の機械学習を作る。 高い品質のデータと機械学習の基礎知識があれば短期間で構築可能 数万円で始められる Q.アノテーションを自動でしてくれないか。 A.傷⇒多種多様なので、キューピーではAutoインコーラーでハズレ値検知を行うモデルを使...

日時：2019年1月31日　18:50～ 内容： Mix Leap Study #32 - めっちゃわかるAIとKubernetes（GCPUG共催） Kubernetes と Yahoo! JAPAN の取り組み 資料 kubernetes クバネテス kubernetes 3ヶ月に一度のマイナーバージョンアップ yahoo 200+ kubernetesクラスタを運用 kubernetes as a Service をZラボが提供 Linuxコンテナ　システムの他の部分から分離されたプロセス。プロセスがシステムの他の部分に影響しないように隔離し、制限。 Docker　コンテナの実行と管理を行うソフトウェア。ソフトウェアの開発を変えた。 イミュータブルでポータブルな性質だから、自動化・スケジューリングがしやすい。 kubernetesはポータブルである。⇒どの環境で動く kubernetesは成長している。⇒他のマネージドよりも利用者数が多い。 なぜkubernetesか？機能面 頻繁なデプロイに耐えられる非常に優れた機能を持つ 時間のかかるデプロイは問題があったときにの修正も遅れる。 頻繁なデプロイは問題もすぐ修正でき、リスク低 宣言的設定→以前は順番に変更（インストール・デプロイ）をしないといけなかったが、「のぞましい状態」を記述した設定ファイルを反映する。宣言的設定によるロールバック。 自己回復機能「セルフヒーリング」→障害時（ノードが死んでも）に自動回復する。 コンテナ中心のインフラ サーバリソースの隙間問題の解決 vmの抽象化に加えて、itインフラも抽象化（ロードバランサーや永続ストレージ） kubernetesオブジェクト　ワークロードやITインフラをアプリケーション指向に抽象化したもの Pod　複数コンテナと、ボリューム。デプロイの最小単位 ReplicaSet　コンテナの数を管理 Deployment　デプロイを管理。内部的にはReplicaSetを使用。 Service　仮想IPとポートを持ち、ラベルセレクタによるPodのグルーピングを行う。Service名によるサービスディスカバリ。 minikube　ローカル開発用クラスタ開発 アプリケーションを Kubernete...

SRE（サイトリライアビリティエンジニアリング）の備忘録 徹底と献身、準備とドキュメンテーションの価値を信じること。 運用（定型）業務の合計を50％以下に。 明文化が大切（業務、環境）。 ポストモーテム→事後検証・振り返り、レビューの重要性。 エラーバジェット[許容可能なエラー率（時間、範囲やレベル）]→いかなる場合でも100％を目指すのは間違い。 1章 モニタリング→サービスの健全性と可用性を追跡（アラート、チケット、ロギング、有効な出力）。 変更管理の自動化→繰り返しタスクに対して疲労、慣れ、軽視、不注意といった一般的な問題を回避。 3章 稼働時間を最大化するよりも、可用性におけるリスクとイノベーションの速度、およびサービス運用の効率性とのバランスをとる。 停止時間よりもリクエスト成功率を可用性の定義とする。 可用性はサービスが提供する機能と市場におけるサービスの位置づけによって決まる。 カナリアテストを組み込む設計 SLO－稼働時間＝損失可能な信頼性 4章 SLI/SLO/SLAの違い SLOは『SLI ≦ ターゲット、もしくは下限 ≦ SLI ≦ 上限』 5章 トイル≠やりたくない仕事 雑務＝オーバーヘッド ただし、つまらない仕事には長期的な価値があることも。 トイルの定義 サービスを稼働させることに関係のある作業 手作業で繰り返し行われ  自動化する事が可能 戦術的で長期的な価値を持たず 作業量がサービスの成長に比例する傾向を持つ 6章 4大シグナル→レイテンシ、トラフィック、エラー、サチュレーション（システムリソースの利用率） ページに人が対応するという事は未来のシステム改善にあたる時間が無くなるという事。 11章 運用の負荷を計測（日々のチケット、インシデントなど） 28章 SREの教育方法『推奨されるパターン』と『アンチパターン』、特にアンチパターンは普段の業務で行っていないか参考になる。 『オンコールとその先へのSERの立ち上げの設計図』（抽象的↔実践的方法） 意識的に理論と実践を適切に組み合わせて学習させる。 学習とプロジェクトを担当させることで、目的と生産性の感覚を身につかせる。 30章 正式なSLI/SL...