2019年7月27日土曜日

慶應義塾大学理工学部創立80年記念イベント(2019/6/26)感想等 -量子コンピュータ編(午後)-


【関連記事】





********

IBM Q Network Hub @ Keio University presents 量子コンピュータ最前線(午後)

午前より参加者がかなり多い。開始五分前で1F席がほぼ埋まっていたようで2F席に案内された。(午前は1F席も割とガラガラだったが。)外国人が多く、日本語講演も特定の人たち向けの同時翻訳が行われていた様子。

挨拶(慶應義塾大学 理工学部長 岡田英史氏)

  • モアムーアの世界に到達しているが、何が起きるのかは予測できていない。昨年IBM Qにアジアで唯一接続できる拠点として選択されたので、量子コンピューティングセンターを立ち上げて研究推進。アジアのハブなので協力企業の参加もあり精力的に推進している。


量子コンピュータ最前線(慶應義塾大学 理工学部 教授 量子コンピューティングセンター ファウンダー 伊藤公平氏)

  • 量子ビットではふり幅と位相。棒磁石で考えると、古典ビットでは縦向きとその逆しかありえず横向きがエラー。量子ビットはラビ振動でエネルギーを与えているうちは振動を繰り返す。横向きは0でもあり1でもあり、測ってみると50%の確立で0。これがものすごいパワーになる。それを2つ準備すると、最初0からエネルギー与えて横向きにして、もう一つは少し遅れて同じようにして、の差(位相差)が重要。これらすべてを利用することで量子コンピュータのパワーが発揮される。
  • 3つの量子ビットを横向きにすると、000でもあり001でもあり8通りの数字を含む。10進数でいうと0~7までの数字すべてを含み、2のn乗通りの数が一気に処理でき、200量子ビットは2の200階乗、1.6×1060乗、宇宙の原子数を一気に計算できる。
  • 初期かはすべて上向き。演算でNOTにして逆向き。1つの量子ビットの状態で位相を変える(量子ビット演算)で、すべての量子コンピュータプログラミングが実施される。最後に一つ一つ読みだす。ふつうのPCと違うのは0or1ではなく0でも1でもありさらに位相に情報が載る。量子ビットの数が多い、演算精度、回数、速度が性能指標。100%の精度は得られないので精度が問題。情報を失うまでにどれだけ回数ができるか。Quantum Volume(量子体積)はIBM提案の指標で、大きくなるほど性能があがる。
  • 今の量子コンピュータはゲート方式、万能量子コンピュータ。IBMGoogleRigetti等。イジングマシン方式(最適化方式)、アニーリング方式、レーザーネットワーク方式等もある。
    • アニーリングは量子ビットをたくさん用意して真横にして重ね合わせて相互作用を操作して自然に落ち着くまで待つ。積極的にゲートでNOT演算しない。D-WaveNEC。古典コンピュータによる量子アルゴリズムを行うシミュレータ・シミュレーションもある。「シミュレーションの結果」とは古典で量子走らせたものを言う。それを早くすると、日立CMOSアニーラー、富士通デジタルアニーラー、東芝シミュレーテッド分岐アルゴリズムがあり。
    • レーザーネットワーク方式は準量子。国立情報学研究所とNTT
  • アメリカは220億円/年。日本は220億円/10年(Q-Leapプログラム)。ヨーロッパでもPJあり。中国では知らないレベル。
  • 日本は基礎研究は相当進んでいる。Top1%論文の割合で、2011年は一位だが今は4位。
  • 量子コンピュータは物理現象の解明、難病の治療薬、人口肥料、その他さまざまな分野へ活用。
  • 超電動量子コンピュータ IBM 50量子ビット。Google72Intel49Rigetti19Intelはシリコンを使って量子コンピュータ作っている。300mmレベルのコンピュータをオレゴンで開発。
  • 意味のある計算をするため、量子ソフトウェア企業が立ち上がっている。MDRMicrosoft等。開発は激烈。何ができるか、を頑張らないと国、企業として負けてしまう。
  • まず、2023年にかけて、現在のコンピュータの発展を支え、ムーアの法則を維持するため、苦手な部分を補完するコンピュータ、ソフトウェアの開発。2028年に、従来の計算性能を飛躍的に超越する量子シミュレータ、コンピュータ、ソフトウェアの開発。Quantum Leap、量子跳躍。
    • それでも一部の分野にとどまる。創薬、化学製品、医学、高度な金融派生商品等。
  • JSTの「さきがけ」で量子の状態制御と機能化、で日本から30名ほど選び研究のアドバイザ、マネジメント。
  • QLEAP予算は産業課のためのスタートアップ資金。投資につながる礎。6つのPJが走っている。冷却原子、シリコン等ハードウェア部門もあり。ソフトウェアも大阪、慶応等。


IBM Q SystemIBMリサーチ IBM Q ネットワーク グローバル・リード Dr. Anthony Annunziata

  • 英語講演+逐次翻訳。
  • Bits + neurons +qubits。将来を担うが唯一の技術ではない。伝統的なPCbitAIneuronを組み合わせて作っていくのが将来のコンピューティング。
    • Bit01.今後何年も継続する。
    • Qubitsは量子縺れ、重ね合わせを基本的な構造として持つ。今後の重要な要素。
  • 単に演算が早い、ではなく、まだ解くことができない難しい問題が解ける可能性があることで騒がれている。
  • IBMでは2年前に3つのPGを立ち上げ。Q SystemQISKIT CommunityQ NetworkQ SystemIBM外部にも使ってもらう。CommunityOpen Software
  • Q OpenQ PremiumSimulator1850万を超えるExecutions。非常にパフォーマンスが高い実行が増えているのも注目に値する。ソフトウェア、ツールもそろえている。研究論文も172件として順調に伸びている。


IBM Q HubKeio(慶應義塾大学 理工学部 教授 量子コンピューティングセンター センター長 山本直樹氏)

  • IBMワトソン研究所にPG送信し、計算結果が戻ってくる。本体があるわけではない。ニューヨーク。ほとんどは冷やすための器具でできている。(←ちらっとPowerPointで出された写真では、有馬温泉にひょこひょこ立っている温泉設備の鉄塔ようなものが山奥にぽつんとある感じ。下は写真では隠されていて分からない。https://newswitch.jp/p/11726 この写真か?(←よく見ると全く温泉設備とは異なっていた……))
  • Hub参加企業としてJSR、三菱UFJ、みずほ、三菱ケミカル等。
  • IBN主催Think2018で登壇。
  • Q誕生前は、実機を使う研究が無かった。実機利用で、改善と発展を肌身で感じ、実装ノウハウ構築。実機による理論検証や実機のための新理論・新技術。まだ量子コンピューティングは開発中でそれにリアルで触れる。Slack上での情報交換。IBM常駐の人も居る。量子金融、化学、AI、システム実装チームの4チーム。
  • モンテカルロ計算(株価変動)。


量子ソフトウェア実装(慶應義塾大学 環境情報学部 教授  量子コンピューティングセンター 副センター長Rodney Van Meter氏)

  • 日本語ぺらぺらな人。
  • Keio Q Hub Teamの4つのチームの1つ。
  • QISKITが標準プログラミング言語。その下にOpen QASMOpen Pulse、そしてHardwareQISKITの上にOptimizersLibrariesApplications。階層化されている。慶応チームはQISKIT中心で全部。Member企業はOptimizersより上。IBMは全部。
    • 注釈:そのものの図がGoogle先生に軽く聞いても無かったが、以下のような図で、QUSKIT中心に横向き▲が描かれている感じ。
  • IBM Qはチップ名TokyoPoughkeepsizeSystem One等で徐々に性能向上。Tokyoは別に東京にあるわけではない(すべてニューヨーク)
  • 良く書かれるもので○は量子ビット、線はCNOT結合。量子ビットや結合の精度が異なっている。品質が違う。その上でシステムをどう組むか。チップの上でどう利用経路を最適化するか。20では縦に4つ、横に5つ、格子状かつ所々×印クロス結合の図で示される。Var x を左上の0yを右下の20とし、どうルートをたどるか。4つあるとQ0, Q1 or Q2, Q3へ。PathA0-1-3)、PathB0-2-3)のどちらがいいか。グラフ理論。QOPTER(コンパイラ)。コンパイラとハードウェアをともに改良すると性能改善。(← https://miro.medium.com/max/700/1*u0Ly-RliQusIH-qNZkTcqw.png のような図の説明)
https://medium.com/@jonathan_hui/qc-quantum-programming-implementation-issues-51e3a146645e
  • 簡単な回路は計算途中はシミュレータで確認できるが、複雑なものを実機で使うと量子が壊れる。ソフトとハードは一緒に進化すべし。今後手動最適化手法の自動化、大規模ソフトウェア開発ツールが研究テーマ。
  • 今後はAIネイティブだけではなくQuantum Nativeへ。


量子AI(三菱ケミカル株式会社 Science & Innovation Center 主任研究員 高 玘氏)

  • 量子AIチーム。目標としては手法の開発、実機の使いこなし、実データの計算。量子コンピュータへのデータを埋め込む手法の開発、量子コンピュータ版機械学習手法の開発、実機を用いたベンチマーク、実機を用いた金融・科学の計算、の4つに分かれる。
  • IBMは世界で初めて実機でAI研究を行い、natureに掲載。
  • 2020年には37%のデータにビジネス上の価値がある。40ZBのデータ量。計算のスピードUPは必須。AIでも量子コンピュータと同様に相互作用の重ね合わせ状態を作成することで、短時間で機械学習できないか。現在は実験場Quantum Ready、その後Quantum AdvantageQuantum Business。現在のうちから人材育成を。
  • 株価が上がるか下がるか、貸付OKか、みたいな分類問題。AIにおいては重要。古典よりbig data解析に優れていると期待されているが、予測精度にばらつきがあり、実用に向けて改良が必要。
  • 古典派データセットからAIKernel計算、AI分類でボトルネックがKernel計算。ボトルネック部分を量子にエンコードして計算。エンコードの改良も必要。量子空間を作成し、計算後、実空間へ戻す。(16次元)
  • Keio Q Hubでは最先端の実機が利用でき、分野横断で専門家がおり、研究を進める環境が整っており、大学とIBM、参加企業の協業で、予想以上に研究を進められる。量子AI実用はここ数年は正念場。ユーザ企業として世界に後れを取らず長期目線で積極的に研究を進めることが重要。今後競争が激しくなる。


量子金融(みずほ情報総研株式会社 サイエンスソリューション部 チーフコンサルタント 宇野隼平氏)

  • 金融業界ではテクノロジーデジタルを起点と舌構造改革を推進。新技術の1つとして量子コンピュータに注目。他にAI、ブロックチェーン、IoT、ビックデータ、クラウド。
  • 量子金融チームはみずほ、三菱UFJファイナンシャルグループ。他に大学教員、IBM
  • 金融商品価格評価への適用。様々な価格変動シナリオを考慮しシミュレーション。長時間コンピュータを使う計算の一つ。量子コンピュータの重ね合わせ状態を使うことで、様々なシナリオを同時に計算することで高速化への期待。2018年、Xanaduからアルゴリズム提案。IBMで実機を用いたデモ計算。
  • 現在の量子アルゴリズムは量子演算の回数が多い。多いと計算困難。より短い演算へ。提案手法は量子コンピュータで別々に実行し古典コンピュータで後処理。長さを95%削減。2019年に共著論文として公開済み。ただ実機だと理論値ほど性能がでない。ノイズの影響。(5量子一般公開だと)
  • Q Hubは金融機関以外の知見も活用しオープンイノベーション。今後JPMorgan等との提携も視野。他の金融機関の参加もお待ちしております、と。


量子科学(JSR株式会社 四日市研究センター マテリアルズ・インフォマティクス推進室 次長 大西裕也氏)

  • JSRと三菱ケミカル。
  • なぜ化学?:化学現象のより深い理解で分子、材料のデザイン。化学現象は熱力学、統計力学、量子科学で表現。量子科学は材料の微視的、電子的性質に深く関与し、精密に制御できれば革新的材料の設計へつながる。ただ従来の手法では精度が不足。
  • 太陽電池、発光デバイス、分子スイッチ、窒素固定、電極反応等。高精度な量子科学計算が必要な課題が多い。
  • 量子科学の問題を高精度に=正確な波動関数を得る、表現すること。電子が詰まっているものを1、入ってないものを0としてマッピングし自然に表現できるのでは。仮に質の良いQubit100できれば、一番量子科学への応用が早いのでは。現在の古典では2,3原子が限界でこれ以上増える見込みが薄い。
  • 量子位相推定アルゴリズムと、変分的量子固定値計算法の2通りが提唱されている。
  • リチウム空気電池のVQE計算。現状の電池より5倍以上の性能が可能。充放電に関わる化学反応を計算し、材料設計への応用につなげる。AlgorismUse CaseHardwareをくるくる回しつつ、Software、モンテカルロ、AIを組み合わせる。


パネルディスカッション

  • 会社紹介となぜ参加したか
    • JSR株式会社 四日市研究センター マテリアルズ・インフォマティクス推進室 室長 永井智樹氏
      • 合成ゴムを作る会社として半官半民からスタート、その後民営化。半導体材料、ディスプレイ用材料も手掛ける。光ファイバとかも。戦略事業としてバイオ系へ。B to Bビジネスで、客の要望に応じてカスタマイズしていち早く届けるところで強豪と戦っている。いかに早く試作品を届けるかはキーになる。量子コンピュータの計算能力は材料開発のブレークスルーになるのではと思い参加。
    • 株式会社三菱UFJフィナンシャル・グループ 事務・システム企画部 上席調査役 栗山英樹 氏
      • 金融課題をグループ全体で拾い上げて解決できないか検討。経営環境の変化+テクノロジーの変化。既存のビジネスモデルそのものにチャレンジすることが必要。紙の資料をデジタル化、大切な話だけを人が受ける、融資判断スピードのUP。取り組まないと金融業自体が成り立たなくなる。
      • デジタライゼーション戦略。改善、改革、非連続。量子コンピュータは技術の谷を越えた非連続部分にある。パラレルでやっていかないとダメ。改善はAIやビックデータ。改革はAIによる業務判断、審査等。Q Hubで、人材育成、攻め、守りのアプローチに期待。暗号プロトコル、機械学習、ポートフォリオリスク管理等の最適化。銀行はかなりのシステムがあるがいつから変えるか、機械学習はいつから丸一日回さなくても済むのか。ある日突然PCをもらってできる話ではない。
    • みずほ情報総研株式会社 サイエンスソリューション部 次長 加藤大輔氏
      • Fintechの流れ。変革が加速している。ビックデータ、AI、分散型台帳、ブロックチェーン、スマートフォン送金。Q Hubで汎用型量子コンピュータの活用に関する研究を開始。今は基礎研究。One MIZUHO戦略でグループ一体で客の課題を解決。みずほ情報総研のサイエンスソリューション部では50年近く、100%外向けで、研究開発部門の客の課題解決。金融系以外でも。汎用型量子コンピュータで何ができるか、できないか、できそうか見極め、できそうなものを対象に、どうすればできるのか検討中。使えるようになってから参入ではなく、今から参入することが必要。
    • 三菱ケミカル株式会社 新事業創出部 上席主幹研究員 竹内久雄氏
      • 6つの成長ドライバーを組み合わせた成長戦略。生産性向上・効率化による競争力、R&DM$A、、、。
      • R&Dでは分子設計、機能設計、共通基盤の組み合わせで様々な製品の開発。「デジタル材料科学」はこれからのキープラットフォーム。化学物質は星の数ほど多いが探査できている数は限られている。次の新しいものを星の海から引っ張ってくる。デジタル変革の波の中で、材料のモデリングの意義を改めて見直す。3,40年前から量子っぽい計算をやっていた。そしてAIも一つのフェーズ。量子コンピュータがチャンスか脅威か。破壊的技術か。それそのものを理解して自らやっていく必要がある。AIと違うものを探すのもミッション。
  • 目標が達成できたか? 感想と期待
    • JSR
      • まだ。結果は出ておりこれから重要になる論文も出てきている。期待を上回っているが。得たものは、人材育成。急にPC持ってこられても対応できないのでネイティブ人材を。量子コンピュータに対して距離感が分かってきた。当初は期待過ぎたが。解決すべき問題が分かってきた。2020年代後半くらいにビジネス適用計算ができるのではと期待。まだEarly Stage
    • MUFG
      • 一周年。走りながら組織を作り、試行錯誤しつつ、最終的に金融チームで論文2本。会社にも持って帰った。実機に触りながら今の実力を把握できた。それぞれが自分が何をすべきか、イノベーション、どう実装するか、でもう一段上の発想を実感として持ってこられたのが成果か。発信も一緒にしていきたい。Hardwareをお願いしつつUse Caseはグループ一丸となって発掘したい。
    • みずほ
      • 人材育成は進んだ。Hubに入るまで量子コンピュータに触ったことが無かったが、1年で習得し、世界に戦えるレベルまで育ってきた。慶応、IBM、会社、学生の環境が非常に良い。情報が得られやすい。今後について、Hardware進歩は期待したい。Hubの成長も。新しい研究領域で、世界最高域の組織に成長してほしい。
    • 三菱ケミカル
      • 今朝論文が出た。まさか論文が1年で出るとは。現状を一年前は理解できてなかった。量子科学のPGは大きく、とても少人数で1年でできるものではない。高級言語でコンパクトに作れる状況が身近にあることに気が付いていなかった。見通しが1年で得られたのは非常に大きな成果。新しい応用事例を増やしたい。今スピードや精度で追いつかなくてもすぐHardwareが追い付くのでぜひ日本から出していきたい。協調領域としては理想的。
    • 日本アイ・ビー・エム株式会社 執行役員 研究開発担当  森本典繁氏
      • 良縁と幸運に恵まれた。半年で契約、アナウンス、カンパニーにお邪魔、とスピーディー。優秀な研究員。ただのOpen Innovationではなく世界最先端のHardwareAcademia、実学。実際にそれが何に使えるのか最初から視野に入れた研究開発が重要。IBMとしてもどう世の中にインパクトを出せるか難しいが、点と道しるべができたのがIBMとしても成果。世界に初めてのものを触るので、先生も生徒もない。今後、日本の代表として、Hubが世界に先駆け、リードしていくことを期待したい。6,7人から30人までメンバーも増えた。
    • まとめ 慶應義塾大学 量子コンピューティングセンター センター長 山本直樹氏
      • 4社の現場から参加いただき、議論。研究者はオリジナリティだの理論だの言いだしたがるが、役に立つもの、使えるもの、人類発展を捨てないでほしいとのアドバイスをJSRから受けた。産学連携しないと分からないこともある。

慶應義塾大学理工学部創立80年記念イベント(2019/6/26)感想等 -AI編(午前)-

【関連記事】





********

文系・理系を超えたAI(人工知能)活用最前線(午前)

挨拶(慶應義塾大学 理工学部長 岡田英史氏)

  • 理系文系ともにAIすることとなった。文系理系越えた形での初期教育、今後の発展に結び付ける。新しい教育の在り方について話をする。


世界のAI研究と慶応のAI研究(慶應義塾大学 理工学部 管理工学科 教授 山口高平氏)

  • AIブームはもう3回目。知識駆動型AIとデータ駆動型AI。エキスパートシステムは当時10個くらい作ったが限界あり。
  • IBMのワトソン、Project Debaterが知識駆動型最新。(ディベートを行う)
  • ワトソンは社内ベンチャーで結構な売り上げを立てている。Project Debaterはディベートの例として「宇宙探索を助成すべきである」について準備15分、立論4分、反論4分、最終弁論2分。人間の地区チャンピョンと戦う。地区のチャンピョンくらいにはAIが勝てるが全米には勝てないレベルまで。オントロジー。意味リンクでのネットワークを構成。
  • 研究室ではWikipediaで意味ネットワーク作成。ヒト型ロボットで小学生の疑問に答える、老人への体操指導等。(Kinectで動作確認。)哲学者 「神様は存在しますか?」に対して「神と存在は関係ない」と答えた。(リンクが無かっただけ。)ただ哲学者に対しては面白かったとか。
  • Deep Learningによる画像認識コンテスト(ILSVRC)では人間のエラー率5%を超え、2.3%へ。150層近くのレイヤーを持つ。畳み込み型ニューラルネットワーク。認識系。
  • Word2Vec。言語処理系。Google。かなり精度が高い。
  • GAN。生成系。山の写真とモネの絵画から、モネが描きそうな山の絵画を。
  • WaymoGoogleからのスピンオフ)で8km7ドル料金でウェイモワン有料タクシー開始。
  • 事故はテスラ、ウーバーで発生。法律上どうするかは課題。
  • 自動運転解除レポートによる比較だと、18000kmくらいは自動運転できる。(自動運転が難しいと言われ人に変わるまでの平均距離。)現在ほぼアメリカが強いが、中国が延びている。Top10のうち3社中国。日産は300km。Apple社が特許No1だが、停止条件が違うからかランキング外。(レポート:https://www.yutainvest.com/google-waymo-proceed-on-the-way-to-selfdriving-car/ か?)
  • ロボットを小学校に出して実験。ロボットから議論に加わると子供たちは盛り上がる。聞いて答えるのは当たり前の時代。
  • 慶応の学園祭でロボットカフェ実施。接客をPepper、ジュースをロボットアーム。クレープに似顔絵を描く。
  • 質疑応答
    • データ精査の効率化は?
      • データハンドリング専用システムの統合が必要。データハンドリング研究はされている。90%がデータハンドリング。数年前から「大学はそこに関わらない」と言われ、準備中。
    • 専門家からみて教育をどうすべき?
      • 小学校からも講演依頼が来る。AIスピーカが数千円で変えるので、1日喋ってみると良い。体験が大事。AIの限界が分かる。


文系理系を問わず社会が求めるAI人財とは(KPMGコンサルティング株式会社 執行役員パートナー(理工学部 訪問教授)椎名茂氏)

  • コンソーシアム構想段階から参加している。NECAI研究。LISPでごりごり書いていた。そこからPwCKPMG。理工学部訪問教授へ。KPMGAIコンサルティング。スタートアップの支援も。
  • Alpha Goは過去データを学ばず、ルールだけ教えると、3日で人間最強の騎士の水準を越え、40日で既存のAIの能力を超えた。Alpha Goだけで対戦することで、人の変な癖を学ばずに済んだのでは。
  • 家電にAIが付くと終わる感じがある。そろそろ4次ブームが来るのでは。
  • AIプロジェクトの始まり:社長が言う、研究しろと言われる。いいカモ。実験するがなかなか形になるものはない。
  • IT系はプロジェクト組んで複数でやらないとうまくいかない。一人の天才が進めるのでもない。AIプロジェクトはまずチーム発足。まずデータを集めるのが先。データにアノテーションが一番時間がかかるところ。PDCA。プロジェクトを回せる人がAI人財。
  • 高校でも確率統計に加えて行列等AI、データサイエンス理解に不可欠な数学を学べる検討を進めている。大学ではすべての学生がAI、数理、データサイエンスの基本的な素養を身に着ける。
  • 基礎知識として、理論、PG言語、ツール、データ分析、ビジネスモデル考案、PM、企業立案。まずPGできないとおもちゃPGもできない。PythonUnity
  • 学生の就職先希望でコンサルが増えている。講師としてはコンサルは実働企業が無いと動けないので実働企業側への希望を延ばしたいが。研究職希望はあまり多くはない。AIベンチャーを立ち上げたいかに対して半数がYes
  • 理系文系関係なく、発想力、ものつくり、適材適所。データの意味を考えられる人。手が動く人間は必要。AI=社中協力。みんな仲良く総力戦で。


AI・高度プログラミングコンソーシアム」の紹介(慶應義塾大学 理工学部 物理情報工学科 教授 コンソーシアム代表 伊藤公平氏)

  • 学生たちを早くからそだてるためのAI高度プログラミングコンソーシアム。産学共同で取り組む枠組み。1,2年生が学ぶ日吉キャンパスにAI講座、サーバルームを設けた。コーディネータも雇用。
  • 適塾モデル。企画、運営を塾生が担う。コンソーシアム、サークル活動みたいなもの。法人会員9名。見学してアドバイス、実社会における活動の照会、現場見学会、AIコンテスト等。企業としては優秀な塾生との出会いの場。
  • 学生による運営は、Webサイトで公募。相談員、サーバ管理者も。シラバスを作って応募し、コーディネータが書類面接。学生によりさまざまなレベルの授業が準備できる。講義を準備してみると定員をはるかに上回る応募。単位にならないのに応募が多い。ニーズがあり学生の意識が高い。Unityは学部二年生が教えていたりする。欠席した者にもアシスタントが教えたり。競技プログラミングに向けた勉強とかも。
  • 競技プログラミングの例として、画像認識ポーカー。ルールや概要から2週間でプログラム提出。森とか海とかにトランプがばらまかれておりそれからポーカーの手を作る。5チームが提出したが、チャレンジ数はもっと多い。
  • 自らが望んで学び、自らが教えたい学生でできている。Webサイトでいろいろと公開。メンバー企業としてはいつでも参加できる。
  • 全員に初級教育はかなり難しい。(政府戦略で全大学生に初級教育。)サーバ、場所、そもそも講師が足りない。


コンソーシアム法人会員による5分間プレゼンテーション「企業でのAI活用例と求められる人財」(各5分程度)

  • 日産総合研究所 高松吉郎氏
    • 日産はIntelligent MobilityDrivingPowerIntegration
    • 車の中でAIグラスをかけてARつかって表示。車の外の人がアバターとして乗り込んで会話。
    • 今年の秋でProPilot2.0。高速道路での支援。
    • 横浜みなとみらい実証実験。Easy Ride
    • 学んでほしいことは、ITリテラシー(防具)、IT武器、AI×○○IT×○○AIを学ぶだけでなく何に使うか、何をするか。
  • 三井住友銀行 オハラ氏
    • コンサルとして日本総合研究所を持つ。Fintechが花盛り。Watsonをコールセンターに全席導入し、先回りして回答させる。離職率が下がっている。
    • AIを買う超下企業の業績状況変化検知システム、提供。個人向け株式提案サービス。
    • 人材としては、業務に通じている、技術力がある、構想力・デザイン・思考力。DIDXを企画・手動できる。
  • 伊藤忠商事 人事総務部 ノト氏
    • 次世代HRタスクフォース。人材とビジネスの面から。
    • Dole事業では、ドローンによりバナナ、パイナップル生育状況を把握、データの有効活用で生産効率の向上。伊藤忠としては自ら作成というより他のものを有効活用。
    • ファミマプラスチックの需要予測でコスト削減。配属の最適化。
    • 学んでほしいこと:幅広いテーマに興味、様々な人の話を聞いて視野を広げる。疑問を持ち物事を深く洞察。
    • AIや先端テクノロジー仕組みや特徴を把握。事業機会を想像できるトランスレータ。課題を見直し業務効率化を通じた生産性向上。必要に応じてテクノロジーを活用。今後の変化を予測。
  • カシオ計算機 人事部 中村氏
    • AI活用として、コンピュータ診断支援(医用画像)。皮膚疾患診断サポート。大学病院ドクターとの共同開発。スマートWatchでランナー向けAIコーチング。ランニングフォームの解析、アドバイス、コーチング。デジカメや腕時計で培われたノウハウをAI技術とMixさせて新しい事業分野へ挑戦。
    • 人材像:PGAIスキル、想像力、コミュニケーション、リテラシー、ビジネススキル。にしっかり勉強、たくさん遊ぶ、会話、興味を持つ、日経よく読む。
  • ジック SICK シブヤ氏
    • 産業用センサのグローバルリーダ。ヨーロッパ第一位のシェア。40000種のセンサ。
    • レーザを出して降ることで3Dで形状が取れる。車を13種類に分類。適切なルートに案内、交通量コントロール。空港での荷物あずけでトランクかそれ以外かを見分ける。95%は見分けられる。現場レベルで実用となるとまだスタートしたばかり。
    • 求める人材は、技術+マインドセット+社会の仕組み。AIネイティブとして啓蒙、変革を促し、AIファースト社会をリード。社会の仕組み:AI効果予測、権利関係。新しい技術には新しい仕組み。今の学生はAIネイティブ第一世代。
  • SOMPOホールディングス デジタル戦略部 長谷川氏
    • 安心・安全・健康のテーマパークを目指す。
    • 生活習慣病リスク予測AI。東芝の解析技術と組んで実装。個人のQOL、医療費増加改善。台風被害推定AI。被災地対応準備と、防災予測モデル。こちらは今進行中。台風予想から建物被害件数。
    • 人材:知識、探究心、動機づけ、オープンマインド。自分なりのAI人材に。既存事業への応用と新たなビジネスモデル。いろいろな観点を踏まえてAIの本質を。
  • パーソルキャリア サイトウ氏
    • PERSOL。テンプスタッフ、anLINEバイト、doda。売上高一兆円の総合人材グループ。
    • 企業求人票自動作成、マッチング、キャリアカウンセリング音声分析、HR×ブロックチェーン。動画×感情推測。対面×生体計測。AIを用いてより希望に沿った転職支援。ルールベースのマッチングから、機械学習と分散処理で、圧倒的な精度向上。
    • 人材:Business Problem SolvingData EngineeringData Science。データサイエンティスト協会が提唱するものと同じ。はたらくを自分のものにする力を。いかに発想できるか。精度だけではなくビジネスの課題をとらえてどう解決するか。AIだけではなく周辺知識も。
  • 東京海上ホールディングス ワダ氏
    • いざというときにお役にたちたい、をコンセプト。創業140年。
    • 色々なデータと向き合う。いろいろなことが幅広くできる。海外展開。
    • 大規模災害への対応として、人工衛星で被害地データを取得、各種外部データと合わせてAIにより浸水エリアと水深を把握。スピーディな自動支払い。
    • 専用ドライブレコーダを22万代以上に普及。運転データや事故動画で日本最大級。事故時に自動で通報、通話、運転注意喚起等。保険会社への事故報告を不要に。事故状況図を生成、過失割合判定。2年前から自動車保険特約としてレコーダつけることにしてある。事故の瞬間からさかのぼってまでとっている。命もすくっている。後々は自動車会社が付けるようになれば後方サービスを。
    • 人材:挑戦。社会的課題を解決して世の中をよりよくしたいという志を原動力に、真の変革に挑める人材。
  • 富士ゼロックス 根本氏
    • Document CompanyからSmart Work Innovationへ。
    • ミドルキャストのコミュニケーション。(NarrowBroadと比較してMiddleBusiness志向。)顧客の業務プロセスを理解しモデル化、知識DB活用、特定の文書業務に向くAIを。法規制文書、設計文書、申請文書等、客固有のデータの活用。分析に必要なデータは多くないので知識駆動型も組み合わせてドキュメントプロセス透明化。
    • 人材:効率的、創造的、快適な働き方を実現し、企業、組織を強くする。コアコンピテンシーはオントロジー、文生成、テキスト読解、情報推薦、マイニング、人間科学。Innovationを起こすためのQPQuestionPassion)。AI/IT人材像はデータサイエンティスト協会と同じく。



慶應義塾大学理工学部創立80年記念イベント(2019/6/26)感想等 -概要編-


概要

慶應義塾大学理工学部創立80年記念イベントシンポジウムの一つ。AIや量子コンピュータの企業利用がどの程度進んでいるのか、学生はどのような形で学んでいるのかについて聞ける珍しい機会だったので行ってみた。
 午前のAIは、大学でAIの講座をどのように開催しているか、協賛企業が問題解決でどうAIを使っているか、企業として学生に何を求めるか、が中心。各塾生(慶応大学は学生と言わず塾生と言うのか?)が自ら講義に参加し、そして講師まで担う、「適塾スタイル」(と言うらしい)が普通に回っていることに驚き。二年生くらいでシラバスを持って講師役に応募する塾生が居るとか。競技プログラミングは課題を与えられてから二週間でアルゴリズムの検討、プログラム開発から応募まで終わらせる。全体的にかなりレベルが高い感じを受け、今後AIの技術だけでなくビジネススキル、コミュニケーション、企画力等が高い学生が市場に出てきて活躍するのかと思うと、期待できそうでかつ少し恐ろしくもある。文系理系問わず学生にAI教育を行うとの指針が国から出ているそうだが、大学ごとの差は大きそうな感じがある。
 午後の量子コンピュータは、IBM Qにアジアで唯一接続できるのが慶応大学とのことで、日本、アジアから人、ノウハウが慶応に集約されている様子が語られる。古典コンピュータ(現在の形のコンピュータ)でシミュレーションを行うスタイルから、直接、まだ開発・進化中のQにつなぎ、Hardwareと共にSoftwareUse Caseも成長させる。Quantum Ready、その後Quantum AdvantageQuantum Businessへと進み、現在のコンピュータの不得意分野を補うところから、本格的な量子コンピュータの時代に入る。それまでに開発・利用のノウハウを構築しておかないと世界に乗り遅れる。AIはまだ手持ちでなんとかなるレベルだが、量子コンピュータはまだまだハードが限られており、こういうハードと共に成長する組織と共同研究する価値は非常に大きいのだろう。今後ハードまでCommodity化するかどうかあたりの話は聞けなかった。まだIBM Qに関しては、実機がニューヨークにあり、アジアの唯一のHubとして慶応がある、レベル。Hubという組織ができて1年で、量子コンピュータのビジネス利用における課題がかなり明らかになった様子。1年で組織形成から論文共著まで行くのはメンバーにとっても結構速いことだったとか。
 コンソーシアムはあと1年だがメンバー企業も募集中とのこと。



【関連記事】




2019年3月31日日曜日

Google Cloud Kubernetes Day(2019/3/26)感想等


 Kubernetes(くーばーねーてす、と会場案内では発音。セッション担当者によってはくーばねてすとか)という言葉を最近よく聞くようになったが、なかなか周囲のインフラ状況と、コンテナ系プラットフォームの導入、利用とが結びつく気配がない。実際最近どうなっているのか、トレンドとしてどういう方向に向かっているのか、どのように移行するのか(富士フィルムのセミナー一番気になった)等確認したく参加。無料。https://cloudplatformonline.com/2019-google-cloud-kubernetes-day-0326.html
セッションはどれも内容が濃く、実体験に基づく構成、GCPβ機能の紹介も多い。スライドも話も早く、分からない単語のオンパレードなのに、どのスピーカーも話がうまく、各セッションどれもあっという間だった。午後一杯でとにかく用語概要とGCP万歳を詰め込まれた感。メモは単語をメモるだけで精一杯の部分多し。
全体として、「運用を容易にする」、「デプロイ、リリースを容易にする」といったツールは、これまではオンプレミスを前提にOSSで提供されるものを手元にインストールして設定して自分で連携させて使う、が主流だっただろうが、今後、プラットフォームはクラウドを前提とし、Cloud Nativeなツールがどんどん提供され、各クラウドベンダーがツール類を競いつつ、利用者は金さえ払えばあるいは無料サービスとして容易に使えるようになり、使うのが当たり前になる、という時代にとっくに突入している感がありありと感じられた。以前参加したAWS Essentialsの際も同様な感想を持ち、その際は「へーAWS便利だなー」位だったが、さらに標準化が進み、Kubernetesがデファクトスタンダードになり、どのクラウド使おうがコンテナは当たり前(CloudからCloud Native)で、Kubernetesを必要とするようなインフラは、もう自前で持つよりAWSGCPのほうが圧倒的に便利で、AmazonGoogleがどんどん便利なツールを自プラットフォームに入れてサービス競争するから、オンプレインフラ運用を楽に扱える技術が公開されることは今後少なくなるのだろう感が見えているのは、オンプレシステム屋やっている身としては少々不安がある。
(……まぁ、小規模オンプレシステムならそもそもDockerすら必要ないレベルだが。どこかのタイミングでオンプレシステム屋は卒業してクラウドシステム屋にならないと完全に置いてきぼりになるのか、それとも別の道がひっそり提示されているのかはまた別途確認として。)


ベルサーユ渋谷ファーストの広いイベントホールがほぼ満席。席数ベースで参加者1000名近く(=3*約15*約20?)か。 スポンサー企業のブースが6つあったが、あまりブースを推している気配なし。(何をやっているのかブースの外から見て分からないレベルの展示。資料をもらったところだとコンサルとか試験サポートとか。)会場はちゃんと机があったため多少狭かったがノートPCでメモを取っている人多し(スライド公開されないからというのもあるだろう)。キーボード音がうるさいほど。1000人居ると休憩時間のお手洗いは長蛇の列(だから休憩時間が妙に長かったのか……)。水、コーヒーコーナーあり。パンのようなもの配っていたようだが一瞬で無くなっていた様子。終了後に無料懇親会がロビーで開催されていたが、ロビーが人で溢れ、とても懇親できる感じではなかったので、飲まずに退散。
セミナーのTwitterハッシュタグは、「#gc_k8sday
以下、セミナー中、セミナー休憩時間に書いたメモ等。

 

 

KubernetesContainerによる開発の導入難易度とメリット(サイバーエージェント青山真也氏)(@amsy810

概要

Kubernetesべたぼめ。ただし、オンプレよりGKEhttps://cloud.google.com/kubernetes-engine/?hl=ja)とセットで考えないといろいろ辛そうな感じはある。Cloudは普及し始めたがCloud Nativehttps://www.publickey1.jp/blog/18/ibm_cloudnative_pr.html)の考えを入れるべし。アプリの組み方、セキュリティ面は考慮必要。学習は楽ではないが、利便性に比べて学習コストは低い。(=学習超大変だがメリットかなり大きい。)

メモ

  • 2016年頃から採用。オンプレミスで独自のKubernetes as a Service基盤。新規事業多くがKubernetes/Container利用。44%GKEGCP。オンプレミス44%AbemaTV3年前からGKE。チャレンジングなワークロードにもGKEAdtech studioでは新規案件90%GKEGKEクラスタ運用自動化機能をフル活用。レイテンシ要件にシビアなアドテク領域OK
  • GoogleクラスタマネージャBorg(ぼーぐ)(https://www.slideshare.net/ktateish/google-borg)を元にしたOSSで、長年のGoogleの経験がKubernetesに引き継がれている。今はCloud Native Computing Foundationsが中立的にホスト、コミュニティによる改良。
  • 歴史:Baremetal EraBootstrappingConfigurationOrchestrationKickstartShell ScriptJenkinsあたりが自動化の始まりだが各社秘伝のコードになりがち。クラウドでは、TerraformChefAnsiblePuppetSaltFabricCapistrano。構造化、共通化された自動化。だが再現性が高くなく時間がかかる。そこからTerraformDockerKubernetes。クラウド非依存の共通化された仕組み。
  • CloudではなくCloud Nativeへ。参考になるのが「Cloud Native Trail Maphttps://labs.mobingi.com/cloud-native-landscape-trail-map/)」。どういったことをすべきかが載っている。コンテナ、オーケストレーションツール。CI/CD
  • まずDocker。アプリケーションと実行環境のイメージ化。
  • Load BalancerStorageも抽象化。Load Balancer作るManifest、転送先のポートとコンテナ指定だけ。
  • 利用者から見るとクラウド固有の知識が不要に。
  • 宣言的なAPICodeYAMLManifestInfrastructure as a Code
  • Control LoopReconciliation。登録された瞬間3つコンテナが普通。KubernetesControl Loopがずっと回っているサイクル。現在のコンテナ数、状況と理想状態の比較、差分に対して処理。障害時に自動的にコンテナを他のノードで起動。(セルフヒーリング。)こういうのがいろいろと準備されており運用が楽。
  • アプリアップデートの際にLoad Balancerから外してUPしてまた入れて、があるが、こういうところも自動化。Manifest変更のみ。どのイメージを使うかのVersionを書き換え。差分検知してUpdate
  • Serverless on Kubernetes。サーバレス環境。Service Mesh。周辺ツールもGoogleが提供していたりする。Managed Service
  • KubebuilderOperator SDKで、Kubernetes自体を拡張して自動化できる。Jenkins等をKubernetesに任せられる。拡張はそれほど難しくない。ループのフレームワーク。
  • ただ導入には覚悟が必要。アプリケーションの作り方を変える。モノリスティックではなくマイクロサービスに適している。コンテナの場合非常に頻繁に停止するのでそういう設計を。SIGTERMハンドリング。ネットワークもIPアドレスを意識しない設計を。アプリToアプリ通信でService Discovery経由通信。SourceIP消失。一部知識必要。セキュリティ回りも難しい。runCKernel共有で影響受けやすい。gVisor等分離性高いContainer Runtime。コンテナ間通信が筒抜けなのでNetwork Policy有効に。
  • 学習コストは小さくはない。Cyberagentでのアンケートでは、つらい50%、導入してよかった100%。
  • 一番つらいのはKubernetesクラスタ管理。GKE使うと解放される。オンプレはしんどい。GKEオンプレもあり。オンプレでGKE使うと楽になるだろう今後は。
  • Managed Kubernetesではマネージドの範囲重要。
  • Cloud Nativeで組織力強化、開発力向上できる。セキュリティだけには注意のこと。最高なツール。
  • 本はGKEベースで書いている。

コンテナ開発プラットフォームにGKEを選択すべき7つの理由(GoogleCloudJapan岩成祐樹氏、田中xx氏)

概要

 冒頭で、7つと言いつつ5つにしますとの話あり。クラウドを使う理由の44%がセキュリティという話にはびっくり。もう「クラウドはセキュリティが……」と言う時代ではなくなった。ただ、あちこちのセッションで、「セキュリティ注意」発言がある。適切な設定をすれば強固だが、ど素人がマイクロサービスなんてやると穴だらけになりかねないのだろう。(http://www.mpon.me/entry/2017/04/22/020428 によるとすべて外部にネットワーク出ている????)
Stackdriverhttps://cloud.google.com/monitoring/?hl=ja)の話は別セッションでも出てきたが、LoggingMonitoringMicroService連携確認等、Cloud使うなら必須だろう。

メモ

  • Security
    • Kubenetesを採用する多くの理由はAgilityだが、Enterpriseで使うならSecurityGoogle CloudSecurityは評価されている。クラウドの長所へ。一昔前と違い、今はSecurityがクラウドを選ぶ理由になっている。徹底的な防御がデフォルトでONになっている。通信、IdentityHardware Infrastructure、運用とデバイスセキュリティ、ストレージ、サービス面。
    • コンテナのセキュリティは3つのレイヤー。インフラがコンテナ開発に安全か。作成したコンテナがビルド、デプロイして問題ないか、作成したコンテナを実行して問題ないか。
      • Use RBAC and IAM。適切な権限管理。プロジェクトレベルではIAMNamespaceではRBAC。必要以上にノードをさらさない。信頼された領域のみのアクセスに絞る。Kubernetes Masterも承認されたネットワークからのみ受け付ける。Cloud ArmorLoad Balancerレベルでセキュリティ。Backend Config BETA
      • 作ったアプリやライブラリがセキュアか、セキュアで持って行けるか。CI/CDパイプラインは信頼できないデプロイを止めてはくれない。Software supply chainで制御。意図したところでビルドされているか、テストされているかをメタデータとして持つ。Container Registry脆弱性スキャン。Binary Authorizationは門番代わり。意図したプロセスに乗っ取ったもののみ本番に行けるように。
      • Runtime SecurityContainer Optimized OSChromiumOSベース。セキュアで軽量な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へ移行。MonolithMicroServiceに徐々に。完了したものからGKEへ。API gatewayでルーティング、トラフィック割り当て。On-Premで動かすのが適したものは残しておく。今後Istio Service MeshOn-PremGKEへ。
  • Observability(可観測性)
    • ロギングとモニタリング。StackdriverLoggingMonitoring機能。Stackdriver Kubernetes Monitoring BETAKubernetesワークロード最適化Stackdriverツール。MonitoringLoggingを1つの管理画面で。CPU使用量、コンテナ状況等。クリックするとLogging画面。一つのUIで。従来のStackdriverからの移行も可。
    • Works With OpenSourcePrometheusCloud Native Monitoring ToolCustom MetricsPrometheusStackdriverとのシームレスインテグレーション。GitHub上でコード公開されたOSS
  • Contribution
    • Open Source is free like a puppyOSSはメンテし続けないとダメ。OSSの活動はUPでは終わらずCommunity活動。Issues、マージ。
    • GKEは、To be ReliableScalableOpenへ向かっていく。
      • Regional clusters。マスターを、ゾーンを跨って分散。
      • Regional Persistent Disks。ブロックレベルレプリケーション。
      • Node Auto-Provisioning BetaPodの水平、垂直スケーリング、Node水平スケーリングに加えて垂直も。4番目のオートスケーリング。
      • SkaffoldKanicoKnativeGoogle ContainerToolsGitHubにあり。



GKEを用いたレガシーシステムからのリプレイス事例(富士フィルム小林だいすけ氏)

概要

富士フィルムのコンシューマ向けレガシーサービス(10年運用)をGKEを用いてリニューアルしたときの話。この数年でGCP、コンテナがいかにデファクトスタンダードになったかあたりの歴史話、それがどう自分たちに影響したか、という話もかなり興味深かった。最新技術を選定する場合に「OKかどうか」の判断基準として参考になりそう。
2018/1頃にKubernetesがデファクトスタンダードになり、Kubernetesの開発元であるGoogleGCPも国内正式サービス開始したので、一気に開発・移行した。ただ、Googleエンジニアが優秀で多分いなければ回らなかったのだろうとスライドの端々で語られているし、社内の協力体制構築、抵抗勢力への説得回数は「∞」、勉強、熱意等、単純に「では移行しちゃおか」では済まない感も満載。1つのプロジェクトで、誰も経験が無く、自分だけでGCP、社外に頼らない、というのはまず失敗するだろう感。(スピーカ自身もこれまで何度も失敗していることを端々でにおわせている。)

メモ

  • 富士フィルムでプリントビジネス関連開発担当。FUJIFILM Prints & Giftshttps://pg-ja.fujifilm.com/photo-print)。注文管理システム(OMS)。
  • 運用10年で保守コスト大、機能開発スピード低下。モノ消費からコト消費へユーザの消費動向変化。2018/1PJ開始。
  • Cloud StorageStackdriverSQL、、、、、
  • 富士フィルムの分化として、STPDCASeeThinkを重要視。現状分析し、やりたいことが間違っていないかの検証重要。
  • レガシーシステムはモノリシックなアプリ(大きい)。負荷状況にリアルタイム追従は困難だった。季節イベント、キャンペーンで負荷増大。年賀状等。負荷量変動への対応を最優先に。2016年ごろからコンテナ調査。DockerKubernetes等使ったが運用大変。安定運用難しくハードル高かった。今は期が熟した。(2018/1) ただコンテナ利用実績なし。急に使って大丈夫か、という声があったがチャレンジングだからやらせてほしいと。「何が標準?」「自分たちで運用できる?」が問題。オーケストレーションツールは使いたい。早目に飛びつくと後悔した例もあり。本番で安定運用、自分たちで理解できる担保ほしい。機能先行ではNG
  • 2014/5Googleは既にすべてのSoftwareContainerに載せ、週20億個コンテナ起動と発表。2014/6Docker1.0KubernetesOSS2015/6にコンテナ標準団体発足。2015/7CNCFDocker SwarmKubernetes主権争い。2017/7OCI1.0.標準化。2017/10dockerKubernetes統合とサポート発表し、Kubernetesが事実上の標準へ。MicrosoftAmazonKubernetesサポート。結果、Kubernetesがコンテナオーケストレーションデファクトスタンダードになり、規格争いによる技術陳腐化懸念後退。主要クラウドベンダがManaged Service開始により安定化。
  • 2018/1時点で日本国内でのGAGoogleのみ。他はβ。正式サービス運用は大きな判断基準。SLAがあるかないか。Kubernetes開発元、4年以上の安定動作運用実績も魅力。Managed Serviceはユーザが対応できない領域も増えるため、安定動作実績はほしい。GKE選定決定。
  • 周りの理解。技術的優位性。リスクを背負えるか。総論賛成だが各論が。納期。近道はなし。技術学習と解説資料と説明行脚を繰り返す。延々と。現場レベルでは味方多し。今のがいいとはだれも思っていない。薄々皆気が付いていた部分での連帯感。リスクは解がなかったがBackup Plan準備。技術習得説明。Google Engineerのバックアップ。(実際の運用、サポート者からの話。)
  • 技術はゼロから。独学+ハンズオン+GoogleEngineerSupportTry&ErrorGKE使いやすさの効果。
  • 効率的システム間連携知識が必要。Pub/sub。レガシーシステムルール把握が難しくシステム引きずりが見えづらい。当初プログラム制御でイベント発火。そこから、ファイル配置でCloudFunctionsで配置イベント検知からPub/Sub投げ込みへ。(CloudStorageに置くとイベントがとれる)
  • LoggingAlertは最終的にうまくできたがMetrics書き方が迷った。CGPDocumentが手薄。GoogleEngineerSupportYaml書き方の勘所慣れが大変。レガシーシステムの設計思想が合っていない。設計上のキーになる部分の調査が必要だった。
  • サービス分離が困難。Max分割したが制御不能。リカバリパターン複雑に。グループ化して分離。MicroService思想は入れたがとにかく小さくするのはダメだった。
  • ManagedServiceでカバーできる範囲の見極めが必要。不足する部分は自前。監視面は社内別PJと近いものを。PaaSについてGoogleEngineerSupport受けつつ選定して確認。Prometheus+自前でリッチな監視を。
  • レガシーシステムとの連携は困難。大部分移したが移せないものあり。新しく作ったシステム側で対応。IP制限、連携プロトコルを古いものを使った。一番最初には「すっきり」(全部新しく)を描いていたが困難。乗り換えたい。
  • 結果、スケーラビリティ確保はできた。ただ今後の悪化注意。現状、注文が瞬間的に数倍に増加しても処理速度劣化なし。他国展開、横展開しやすい構造へ。保守運用コストも改善。保守コストは1/2.サーバリソース有効活用でランニングコスト3/5へ。導入8か月でサービスダウンタイムなし。安定動作。ログ調査やアラート連携一元管理で改善。今後の分析基盤ベースに。機能改善スピードも向上。約2倍。イベント開催にも柔軟に対応可能な構造へ。
  • GKE学習コストは得られるリターンに比べたら小さい。(学習コストは大きいがリターンが大きい。)従来比でインフラ懸念を取り除けた。組み合わせの話や深いところの理解はまだ勉強必要。クラウドベンダのエンジニアの協力が偉大。導入には熱意必要。一人では負けるので仲間を。



コンテナによる開発と運用の進化(GoogleCloudJapan村上大河氏、篠原一徳氏)

概要

MicroServiceは最近はやっているというので本を何冊か読んだが、これまで手掛けたサービスはサービスをそこまで切ってサーバに別々に立てるほど大きくないので「へー」で終わっていたが、大きなシステムだとログインだの検索だのそれだけでも抜き出してサービス化となる。Microserviceどうしの通信のAPIをどう管理するか、バージョニングするかのノウハウがGoogleから公開あり。Istio等を使うとどこから呼ばれているか等も管理できる。

メモ

  • 技術サポートの人。MicroServiceの話をする。聴衆でMicroServiceでシステム組んでいる人と言われ手を挙げたのは少なめ。
  • いいものを早く届けるために、リリースする規模を少なくするのがPracticeMicroServiceArchitectureの採用。ポイントは人、プロセス、Technologyの3つ。(イテレーションを早くするには。)企業ごとのやり方に最適化を。WaterfallからScrumへの変化への反応。BusinessProcessをどう技術に合わせて変えるか。Change ManagementTechnologyに対する変化の管理。Googleや提携パートナーからそういう変化のサポートを行うサポートあり。こういうイベントでも発表あり。
  • MicroServiceは機能ごとに独立したアプリ、サービスに分割。サービスは単一の目的。サービス間は租結合。軽量なAPIでやりとり。
  • Asls to ToBeMonolith to Microservice。新規サービスからやる。既存サービスを部分的に置き換える。理想的には開発とビジネスとを1:1の組み合わせをたくさん。ただ複雑にはなるので、今までのアーキテクチャ向けでは監視、管理、保護は困難。イテレーション速度を上げるにはネックになる。
  • 4challenges of Microservices。1)プロセス内コミュニケーションからプロセス外コミュニケーションへ。RPCAPIゲートウェイ。2)分散システム導入による複雑化システムの効率管理。サービスメッシュ。3)マイクロサービス協会が引き起こすデータサイロの解決。データレイク。4)アプリケーション以外のコーディングを少なく。自動化(CI/CD)。本質的な部分に集中を。
    • 1)REST APIgRPC。サービスを分けることで独立して管理できる一方、利用しているサービスを勝手に変えられる危険性。API仕様を変えるとService全体に影響。ルールを作って防ぎつつイテレーション速度を落とさない。宣言的に管理。APIVersion管理。REST APIあるいはOpenAPIで使用定義。gRPCProtocol Buffersでの仕様公開。定義ファイルを利用することで、利用したいAPIのスタブを自動利用、Validation。日々相手のAPIをチェックしつつ開発。Version管理は、GoogleCloudPlatformでバージョン管理ガイドあり。Google内部のAPIバージョニング手法。セマンティックバージョニング。Cloud Endpoint.APIにメジャーバージョン、マイナーバージョン。マイナーバージョンには後方互換性あり。メジャーは下位互換性なし。メジャーバージョンは利用先と互換性担保、連携。自分たちの世界でAPI進化可能。API設計ガイドもGoogleで公開あり。Google内部でのAPI設計スタンダード。一定のルールでMicroServiceを作る。
    • Cloud EndpointsAPIを提供。公開APIに対するアクセスコントロール。API KeysStackdriver loggingAPIコールのログをKeyに紐づけ。VisualizeBigQuerydataポータル。内部向けと外部向けの変更。
    • Stackdriver traceを使い、よりService間呼び出しを効率化。メトリクスはPrometheusで一元化。MicroServiceGCPともStackdriver Monitoringで。通信制御はIstio(いすてぃお。https://qiita.com/Ladicle/items/979d59ef0303425752c8)。
    • 2)サービスメッシュ。MicroServiceではシステム複雑化で管理大変。簡略化のための機能提供。アプリに手を入れずサイドカープロキシ。IstioGoogleIBM中心開発のサービスメッシュ。トラフィックコントロール、サービスレベルセキュリティ、可観測性を提供。
      • これまでトラフィックはインフラと結びついていた。段階的にローリングUpdateLoadBalancerから切り離し、、とかをIstioを使うと制御委託。トラフィックスプリッティング。新しいものに10%流して安全にアプリリリース。
      • Istio使うとMicroService間の認証、暗号化、通信許可ポリシー制御。Role Based Access Control
      • Istioの監視(Service連携監視)機能が入っている。PrometheusJaeger。簡易に管理。
      • Istioはもうボタン押せば使える。今後も機能あり。
    • 3)データレイク。MicroService内データストアをどうするか。データがサイロになりかねない。Cloud PubSub。キューイングサービス。分析に必要なデータを送り込み、集める。
  • Istioデモ。PythonJavaRubynodeGKEクラスタ。Book InfoCloud Service managementIstio GKEGoogleがマネージするIstioβ版。オブザーバビリティ向上。SLO管理。Latency Threshold80%30msec以内のレスポンスを維持しているかを月で見たり。Istioのミキサーでサードパーティと連携。アラートの設定をStackdriver経由で。トポロジーグラフ(MicroServiceどうしの連携)は今年前半くらいにサポート予定。現在付け焼刃程度のはある。
  • Cloud Service Management Alpha募集中。https://servicemesh.page.link/alpha-service (←リンクメモったが間違い)
  • GCPエキスパートに相談を。全面的にサポートする。