セッションはどれも内容が濃く、実体験に基づく構成、GCPのβ機能の紹介も多い。スライドも話も早く、分からない単語のオンパレードなのに、どのスピーカーも話がうまく、各セッションどれもあっという間だった。午後一杯でとにかく用語概要とGCP万歳を詰め込まれた感。メモは単語をメモるだけで精一杯の部分多し。
全体として、「運用を容易にする」、「デプロイ、リリースを容易にする」といったツールは、これまではオンプレミスを前提にOSSで提供されるものを手元にインストールして設定して自分で連携させて使う、が主流だっただろうが、今後、プラットフォームはクラウドを前提とし、Cloud
Nativeなツールがどんどん提供され、各クラウドベンダーがツール類を競いつつ、利用者は金さえ払えばあるいは無料サービスとして容易に使えるようになり、使うのが当たり前になる、という時代にとっくに突入している感がありありと感じられた。以前参加したAWS
Essentialsの際も同様な感想を持ち、その際は「へーAWS便利だなー」位だったが、さらに標準化が進み、Kubernetesがデファクトスタンダードになり、どのクラウド使おうがコンテナは当たり前（CloudからCloud
Native）で、Kubernetesを必要とするようなインフラは、もう自前で持つよりAWSかGCPのほうが圧倒的に便利で、AmazonやGoogleがどんどん便利なツールを自プラットフォームに入れてサービス競争するから、オンプレインフラ運用を楽に扱える技術が公開されることは今後少なくなるのだろう感が見えているのは、オンプレシステム屋やっている身としては少々不安がある。
（……まぁ、小規模オンプレシステムならそもそもDockerすら必要ないレベルだが。どこかのタイミングでオンプレシステム屋は卒業してクラウドシステム屋にならないと完全に置いてきぼりになるのか、それとも別の道がひっそり提示されているのかはまた別途確認として。）
ベルサーユ渋谷ファーストの広いイベントホールがほぼ満席。席数ベースで参加者１０００名近く（＝３＊約１５＊約２０？）か。 スポンサー企業のブースが６つあったが、あまりブースを推している気配なし。（何をやっているのかブースの外から見て分からないレベルの展示。資料をもらったところだとコンサルとか試験サポートとか。）会場はちゃんと机があったため多少狭かったがノートPCでメモを取っている人多し（スライド公開されないからというのもあるだろう）。キーボード音がうるさいほど。1000人居ると休憩時間のお手洗いは長蛇の列（だから休憩時間が妙に長かったのか……）。水、コーヒーコーナーあり。パンのようなもの配っていたようだが一瞬で無くなっていた様子。終了後に無料懇親会がロビーで開催されていたが、ロビーが人で溢れ、とても懇親できる感じではなかったので、飲まずに退散。
セミナーのTwitterハッシュタグは、「#gc_k8sday」
Kubernetes／Containerによる開発の導入難易度とメリット（サイバーエージェント青山真也氏）（@amsy810）
概要
Kubernetesべたぼめ。ただし、オンプレよりGKE（https://cloud.google.com/kubernetes-engine/?hl=ja）とセットで考えないといろいろ辛そうな感じはある。Cloudは普及し始めたがCloud
Native（https://www.publickey1.jp/blog/18/ibm_cloudnative_pr.html）の考えを入れるべし。アプリの組み方、セキュリティ面は考慮必要。学習は楽ではないが、利便性に比べて学習コストは低い。（＝学習超大変だがメリットかなり大きい。）
著者Twitter：https://twitter.com/amsy810
メモ
-
Kubernetes完全ガイドの著者（https://www.amazon.co.jp/dp/B07HFS7TDT/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1）。
-
2016年頃から採用。オンプレミスで独自のKubernetes as a Service基盤。新規事業多くがKubernetes/Container利用。44%がGKE、GCP。オンプレミス44%。AbemaTVは3年前からGKE。チャレンジングなワークロードにもGKE。Adtech studioでは新規案件90%がGKE。GKEクラスタ運用自動化機能をフル活用。レイテンシ要件にシビアなアドテク領域OK。
-
GoogleクラスタマネージャBorg（ぼーぐ）（https://www.slideshare.net/ktateish/google-borg）を元にしたOSSで、長年のGoogleの経験がKubernetesに引き継がれている。今はCloud Native Computing Foundationsが中立的にホスト、コミュニティによる改良。
-
歴史：Baremetal Era。Bootstrapping、Configuration、Orchestration。Kickstart、Shell Script、Jenkinsあたりが自動化の始まりだが各社秘伝のコードになりがち。クラウドでは、Terraform、Chef、Ansible、Puppet、Salt、Fabric、Capistrano。構造化、共通化された自動化。だが再現性が高くなく時間がかかる。そこからTerraform、Docker、Kubernetes。クラウド非依存の共通化された仕組み。
-
CloudではなくCloud Nativeへ。参考になるのが「Cloud Native Trail Map（https://labs.mobingi.com/cloud-native-landscape-trail-map/）」。どういったことをすべきかが載っている。コンテナ、オーケストレーションツール。CI/CD。
-
まずDocker。アプリケーションと実行環境のイメージ化。
-
Load Balancer、Storageも抽象化。Load Balancer作るManifest、転送先のポートとコンテナ指定だけ。
-
利用者から見るとクラウド固有の知識が不要に。
-
宣言的なAPIとCode。YAML、Manifest。Infrastructure as a Code。
-
Control LoopとReconciliation。登録された瞬間３つコンテナが普通。KubernetesでControl Loopがずっと回っているサイクル。現在のコンテナ数、状況と理想状態の比較、差分に対して処理。障害時に自動的にコンテナを他のノードで起動。（セルフヒーリング。）こういうのがいろいろと準備されており運用が楽。
-
アプリアップデートの際にLoad Balancerから外してUPしてまた入れて、があるが、こういうところも自動化。Manifest変更のみ。どのイメージを使うかのVersionを書き換え。差分検知してUpdate。
-
Serverless on Kubernetes。サーバレス環境。Service Mesh。周辺ツールもGoogleが提供していたりする。Managed Service。
-
Kubebuilder／Operator SDKで、Kubernetes自体を拡張して自動化できる。Jenkins等をKubernetesに任せられる。拡張はそれほど難しくない。ループのフレームワーク。
-
ただ導入には覚悟が必要。アプリケーションの作り方を変える。モノリスティックではなくマイクロサービスに適している。コンテナの場合非常に頻繁に停止するのでそういう設計を。SIGTERMハンドリング。ネットワークもIPアドレスを意識しない設計を。アプリToアプリ通信でService Discovery経由通信。SourceIP消失。一部知識必要。セキュリティ回りも難しい。runCはKernel共有で影響受けやすい。gVisor等分離性高いContainer Runtime。コンテナ間通信が筒抜けなのでNetwork Policy有効に。
-
学習コストは小さくはない。Cyberagentでのアンケートでは、つらい５０％、導入してよかった１００％。
-
一番つらいのはKubernetesクラスタ管理。GKE使うと解放される。オンプレはしんどい。GKEオンプレもあり。オンプレでGKE使うと楽になるだろう今後は。
-
Managed Kubernetesではマネージドの範囲重要。
-
Cloud Nativeで組織力強化、開発力向上できる。セキュリティだけには注意のこと。最高なツール。
-
本はGKEベースで書いている。
コンテナ開発プラットフォームにGKEを選択すべき７つの理由（GoogleCloudJapan岩成祐樹氏、田中ｘｘ氏）
概要
冒頭で、７つと言いつつ５つにしますとの話あり。クラウドを使う理由の44%がセキュリティという話にはびっくり。もう「クラウドはセキュリティが……」と言う時代ではなくなった。ただ、あちこちのセッションで、「セキュリティ注意」発言がある。適切な設定をすれば強固だが、ど素人がマイクロサービスなんてやると穴だらけになりかねないのだろう。（http://www.mpon.me/entry/2017/04/22/020428 によるとすべて外部にネットワーク出ている？？？？）
Stackdriver（https://cloud.google.com/monitoring/?hl=ja）の話は別セッションでも出てきたが、Logging、Monitoring、MicroService連携確認等、Cloud使うなら必須だろう。
メモ
-
Security
-
Kubenetesを採用する多くの理由はAgilityだが、Enterpriseで使うならSecurity。Google CloudのSecurityは評価されている。クラウドの長所へ。一昔前と違い、今はSecurityがクラウドを選ぶ理由になっている。徹底的な防御がデフォルトでONになっている。通信、Identity、Hardware Infrastructure、運用とデバイスセキュリティ、ストレージ、サービス面。
-
コンテナのセキュリティは３つのレイヤー。インフラがコンテナ開発に安全か。作成したコンテナがビルド、デプロイして問題ないか、作成したコンテナを実行して問題ないか。
-
Use RBAC and IAM。適切な権限管理。プロジェクトレベルではIAM。NamespaceではRBAC。必要以上にノードをさらさない。信頼された領域のみのアクセスに絞る。Kubernetes Masterも承認されたネットワークからのみ受け付ける。Cloud Armor。Load Balancerレベルでセキュリティ。Backend Config BETA。
-
作ったアプリやライブラリがセキュアか、セキュアで持って行けるか。CI/CDパイプラインは信頼できないデプロイを止めてはくれない。Software supply chainで制御。意図したところでビルドされているか、テストされているかをメタデータとして持つ。Container Registry脆弱性スキャン。Binary Authorizationは門番代わり。意図したプロセスに乗っ取ったもののみ本番に行けるように。
-
Runtime Security。Container Optimized OS。ChromiumOSベース。セキュアで軽量なOS。アップデートが自動。Runc脆弱性事件でも当OSではアクション必要なし。Runtime security partners in Cloud SCC BETA。ベンダのセキュリティツールを一元化。
-
-
-
Network
-
GKEは裏で様々なGCPServiceと統合。裏で何がデプロイされるかがユーザエクスペリエンスに影響。Google Cloud Load Balancing。デフォルトで提供されている。グローバルインフラ。Container Native Load Balancing Betaを使うと直接ネイティブにバランシングでレイテンシ改善。
-
-
Hybrid Cloud
-
コードをどこでも実行できる環境を。適材適所を柔軟に。GKE On-Prem BETA。利用には制約あり。GKEとオンプレのクラスタをGoogleCloudで一元管理できる。Stackdriver可観測性をオンプレにも。結果としてオンプレとクラウドでリソースを自由に。同じツールを使ってクラスタの集中管理。環境の差異を最小化。
-
Mercari事例。On-PremからHybrid Cloudへ移行。MonolithをMicroServiceに徐々に。完了したものからGKEへ。API gatewayでルーティング、トラフィック割り当て。On-Premで動かすのが適したものは残しておく。今後Istio Service Mesh。On-PremもGKEへ。
-
-
Observability（可観測性）
-
ロギングとモニタリング。Stackdriver。LoggingとMonitoring機能。Stackdriver Kubernetes Monitoring BETA。Kubernetesワークロード最適化Stackdriverツール。Monitoring、Loggingを１つの管理画面で。CPU使用量、コンテナ状況等。クリックするとLogging画面。一つのUIで。従来のStackdriverからの移行も可。
-
Works With OpenSource。Prometheus。Cloud Native Monitoring Tool。Custom Metrics。PrometheusとStackdriverとのシームレスインテグレーション。GitHub上でコード公開されたOSS。
-
-
Contribution
-
Open Source is free like a puppy。OSSはメンテし続けないとダメ。OSSの活動はUPでは終わらずCommunity活動。Issues、マージ。
-
GKEは、To be Reliable、Scalable、Openへ向かっていく。
-
Regional clusters。マスターを、ゾーンを跨って分散。
-
Regional Persistent Disks。ブロックレベルレプリケーション。
-
Node Auto-Provisioning Beta。Podの水平、垂直スケーリング、Node水平スケーリングに加えて垂直も。4番目のオートスケーリング。
-
Skaffold、Kanico、Knative。Google ContainerTools。GitHubにあり。
-
-
GKEを用いたレガシーシステムからのリプレイス事例（富士フィルム小林だいすけ氏）
概要
富士フィルムのコンシューマ向けレガシーサービス（１０年運用）をGKEを用いてリニューアルしたときの話。この数年でGCP、コンテナがいかにデファクトスタンダードになったかあたりの歴史話、それがどう自分たちに影響したか、という話もかなり興味深かった。最新技術を選定する場合に「OKかどうか」の判断基準として参考になりそう。
2018/1頃にKubernetesがデファクトスタンダードになり、Kubernetesの開発元であるGoogleのGCPも国内正式サービス開始したので、一気に開発・移行した。ただ、Googleエンジニアが優秀で多分いなければ回らなかったのだろうとスライドの端々で語られているし、社内の協力体制構築、抵抗勢力への説得回数は「∞」、勉強、熱意等、単純に「では移行しちゃおか」では済まない感も満載。１つのプロジェクトで、誰も経験が無く、自分だけでGCP、社外に頼らない、というのはまず失敗するだろう感。（スピーカ自身もこれまで何度も失敗していることを端々でにおわせている。）
メモ
-
富士フィルムでプリントビジネス関連開発担当。FUJIFILM Prints & Gifts（https://pg-ja.fujifilm.com/photo-print）。注文管理システム（OMS）。
-
運用１０年で保守コスト大、機能開発スピード低下。モノ消費からコト消費へユーザの消費動向変化。2018/1～PJ開始。
-
Cloud Storage、Stackdriver、SQL、、、、、
-
富士フィルムの分化として、STPDCA。SeeとThinkを重要視。現状分析し、やりたいことが間違っていないかの検証重要。
-
レガシーシステムはモノリシックなアプリ（大きい）。負荷状況にリアルタイム追従は困難だった。季節イベント、キャンペーンで負荷増大。年賀状等。負荷量変動への対応を最優先に。2016年ごろからコンテナ調査。Docker、Kubernetes等使ったが運用大変。安定運用難しくハードル高かった。今は期が熟した。（2018/1） ただコンテナ利用実績なし。急に使って大丈夫か、という声があったがチャレンジングだからやらせてほしいと。「何が標準？」「自分たちで運用できる？」が問題。オーケストレーションツールは使いたい。早目に飛びつくと後悔した例もあり。本番で安定運用、自分たちで理解できる担保ほしい。機能先行ではNG。
-
2014/5、Googleは既にすべてのSoftwareをContainerに載せ、週２０億個コンテナ起動と発表。2014/6にDocker1.0、KubernetesをOSS。2015/6にコンテナ標準団体発足。2015/7にCNCF。Docker SwarmとKubernetes主権争い。2017/7でOCI1.0.標準化。2017/10にdockerがKubernetes統合とサポート発表し、Kubernetesが事実上の標準へ。MicrosoftとAmazonもKubernetesサポート。結果、Kubernetesがコンテナオーケストレーションデファクトスタンダードになり、規格争いによる技術陳腐化懸念後退。主要クラウドベンダがManaged Service開始により安定化。
-
2018/1時点で日本国内でのGAはGoogleのみ。他はβ。正式サービス運用は大きな判断基準。SLAがあるかないか。Kubernetes開発元、４年以上の安定動作運用実績も魅力。Managed Serviceはユーザが対応できない領域も増えるため、安定動作実績はほしい。GKE選定決定。
-
周りの理解。技術的優位性。リスクを背負えるか。総論賛成だが各論が。納期。近道はなし。技術学習と解説資料と説明行脚を繰り返す。延々と。現場レベルでは味方多し。今のがいいとはだれも思っていない。薄々皆気が付いていた部分での連帯感。リスクは解がなかったがBackup Plan準備。技術習得説明。Google Engineerのバックアップ。（実際の運用、サポート者からの話。）
-
技術はゼロから。独学＋ハンズオン＋GoogleEngineerSupportでTry&Error。GKE使いやすさの効果。
-
効率的システム間連携知識が必要。Pub/sub。レガシーシステムルール把握が難しくシステム引きずりが見えづらい。当初プログラム制御でイベント発火。そこから、ファイル配置でCloudFunctionsで配置イベント検知からPub/Sub投げ込みへ。（CloudStorageに置くとイベントがとれる）
-
Logging、Alertは最終的にうまくできたがMetrics書き方が迷った。CGPDocumentが手薄。GoogleEngineerにSupport。Yaml書き方の勘所慣れが大変。レガシーシステムの設計思想が合っていない。設計上のキーになる部分の調査が必要だった。
-
サービス分離が困難。Max分割したが制御不能。リカバリパターン複雑に。グループ化して分離。MicroService思想は入れたがとにかく小さくするのはダメだった。
-
ManagedServiceでカバーできる範囲の見極めが必要。不足する部分は自前。監視面は社内別PJと近いものを。PaaSについてGoogleEngineerSupport受けつつ選定して確認。Prometheus＋自前でリッチな監視を。
-
レガシーシステムとの連携は困難。大部分移したが移せないものあり。新しく作ったシステム側で対応。IP制限、連携プロトコルを古いものを使った。一番最初には「すっきり」（全部新しく）を描いていたが困難。乗り換えたい。
-
結果、スケーラビリティ確保はできた。ただ今後の悪化注意。現状、注文が瞬間的に数倍に増加しても処理速度劣化なし。他国展開、横展開しやすい構造へ。保守運用コストも改善。保守コストは1/2．サーバリソース有効活用でランニングコスト3/5へ。導入８か月でサービスダウンタイムなし。安定動作。ログ調査やアラート連携一元管理で改善。今後の分析基盤ベースに。機能改善スピードも向上。約２倍。イベント開催にも柔軟に対応可能な構造へ。
-
GKE学習コストは得られるリターンに比べたら小さい。（学習コストは大きいがリターンが大きい。）従来比でインフラ懸念を取り除けた。組み合わせの話や深いところの理解はまだ勉強必要。クラウドベンダのエンジニアの協力が偉大。導入には熱意必要。一人では負けるので仲間を。
コンテナによる開発と運用の進化（GoogleCloudJapan村上大河氏、篠原一徳氏）
概要
MicroServiceは最近はやっているというので本を何冊か読んだが、これまで手掛けたサービスはサービスをそこまで切ってサーバに別々に立てるほど大きくないので「へー」で終わっていたが、大きなシステムだとログインだの検索だのそれだけでも抜き出してサービス化となる。Microserviceどうしの通信のAPIをどう管理するか、バージョニングするかのノウハウがGoogleから公開あり。Istio等を使うとどこから呼ばれているか等も管理できる。
メモ
-
技術サポートの人。MicroServiceの話をする。聴衆でMicroServiceでシステム組んでいる人と言われ手を挙げたのは少なめ。
-
いいものを早く届けるために、リリースする規模を少なくするのがPractice。MicroServiceArchitectureの採用。ポイントは人、プロセス、Technologyの３つ。（イテレーションを早くするには。）企業ごとのやり方に最適化を。WaterfallからScrumへの変化への反応。BusinessProcessをどう技術に合わせて変えるか。Change Management。Technologyに対する変化の管理。Googleや提携パートナーからそういう変化のサポートを行うサポートあり。こういうイベントでも発表あり。
-
MicroServiceは機能ごとに独立したアプリ、サービスに分割。サービスは単一の目的。サービス間は租結合。軽量なAPIでやりとり。
-
Asls to ToBe。Monolith to Microservice。新規サービスからやる。既存サービスを部分的に置き換える。理想的には開発とビジネスとを１：１の組み合わせをたくさん。ただ複雑にはなるので、今までのアーキテクチャ向けでは監視、管理、保護は困難。イテレーション速度を上げるにはネックになる。
-
4challenges of Microservices。１）プロセス内コミュニケーションからプロセス外コミュニケーションへ。RPC＋APIゲートウェイ。２）分散システム導入による複雑化システムの効率管理。サービスメッシュ。３）マイクロサービス協会が引き起こすデータサイロの解決。データレイク。４）アプリケーション以外のコーディングを少なく。自動化（CI/CD）。本質的な部分に集中を。
-
１）REST API、gRPC。サービスを分けることで独立して管理できる一方、利用しているサービスを勝手に変えられる危険性。API仕様を変えるとService全体に影響。ルールを作って防ぎつつイテレーション速度を落とさない。宣言的に管理。APIのVersion管理。REST APIあるいはOpenAPIで使用定義。gRPCやProtocol Buffersでの仕様公開。定義ファイルを利用することで、利用したいAPIのスタブを自動利用、Validation。日々相手のAPIをチェックしつつ開発。Version管理は、GoogleCloudPlatformでバージョン管理ガイドあり。Google内部のAPIバージョニング手法。セマンティックバージョニング。Cloud Endpoint.APIにメジャーバージョン、マイナーバージョン。マイナーバージョンには後方互換性あり。メジャーは下位互換性なし。メジャーバージョンは利用先と互換性担保、連携。自分たちの世界でAPI進化可能。API設計ガイドもGoogleで公開あり。Google内部でのAPI設計スタンダード。一定のルールでMicroServiceを作る。
-
Cloud Endpoints。APIを提供。公開APIに対するアクセスコントロール。API Keys、Stackdriver loggingでAPIコールのログをKeyに紐づけ。VisualizeはBigQuery＋dataポータル。内部向けと外部向けの変更。
-
Stackdriver traceを使い、よりService間呼び出しを効率化。メトリクスはPrometheusで一元化。MicroService、GCPともStackdriver Monitoringで。通信制御はIstio（いすてぃお。https://qiita.com/Ladicle/items/979d59ef0303425752c8）。
-
２）サービスメッシュ。MicroServiceではシステム複雑化で管理大変。簡略化のための機能提供。アプリに手を入れずサイドカープロキシ。IstioはGoogleとIBM中心開発のサービスメッシュ。トラフィックコントロール、サービスレベルセキュリティ、可観測性を提供。
-
これまでトラフィックはインフラと結びついていた。段階的にローリングUpdate。LoadBalancerから切り離し、、とかをIstioを使うと制御委託。トラフィックスプリッティング。新しいものに10%流して安全にアプリリリース。
-
Istio使うとMicroService間の認証、暗号化、通信許可ポリシー制御。Role Based Access Control。
-
Istioの監視（Service連携監視）機能が入っている。Prometheus、Jaeger。簡易に管理。
-
Istioはもうボタン押せば使える。今後も機能あり。
-
-
３）データレイク。MicroService内データストアをどうするか。データがサイロになりかねない。Cloud PubSub。キューイングサービス。分析に必要なデータを送り込み、集める。
-
-
Istioデモ。Python、Java、Ruby、node。GKEクラスタ。Book Info。Cloud Service management。Istio GKE。GoogleがマネージするIstio。β版。オブザーバビリティ向上。SLO管理。Latency Threshold。80%は30msec以内のレスポンスを維持しているかを月で見たり。Istioのミキサーでサードパーティと連携。アラートの設定をStackdriver経由で。トポロジーグラフ（MicroServiceどうしの連携）は今年前半くらいにサポート予定。現在付け焼刃程度のはある。
-
GCPエキスパートに相談を。全面的にサポートする。
