CloudNative Days Tokyo 2019振り返りNightに参加しました
どんなイベントだった？
2019/07/22～2019/07/23に開催された CloudNative Days Tokyo 2019 の振り返りイベントになります。
今回はブログ枠で参加させて頂きました。最近クラウドを始めた初学者目線となりますが生暖かい目で見て頂けますと。（誤記等がありましたらご指摘お願い致します！）
各セッションのポイント等々
ZOZOテクノロジーズより岡様・杉山様が登壇され、マイクロソフトより真壁様が登壇されました。
ZOZOTOWNの描くCloud Native Journey @okahiromasa
・ZOZOTOWNは常時73万点以上・即日配送サービスを展開するECサイトで15年前の27店から現在は1200店と巨大なサイトに成長した。
・ただ、クラウドに乗り出すまではアーキテクチャを変えずに規模を拡大してきた。
➡ IIS / VBScriptがメインでDBはSQL Server、当初は数台だったものの2017年にはLB配下に配置されるような構成に。
【私】「モノリス」というキーワードが頻繁に出てきたものの実はあまり分かっていなかったのですが、下記サイトはマイクロサービスとの比較で非常に分かりやすいです。
これなら分かる！ マイクロサービス（入門編）～モノリスと比較した特徴、利点と課題 (1/3)：CodeZine（コードジン）
・モノリス（密結合システム）のメリット／デメリット
➡（メリ）新規サービスの開発に適している 性能を向上させやすい 高い運用性 等
➡（デメ）運用作業や障害の影響範囲が大 システム全体が特定技術へ依存 コード量増加による複雑さの増大 蓄積する dead code ＆ dead data <- これにより新規メンバーのキャッチアップが困難
・マイクロサービスを目指す理由
➡新しいチャレンジへの基盤 多様な人材と働き方への適応 多様化する技術の活用促進 全体を止めない／全体が止まらない 等
・マイクロサービスに向けたアプローチと進捗
キーワード：Monolith to Microservice／Strangler Application
・「Strangler Application Pattern」とは？
➡機能の特定の部分を新しいアプリケーションやサービスに徐々に置き換えることでレガシーシステムを段階的に移行すること
ストラングラー パターン - Cloud Design Patterns | Microsoft Docs
・マイクロサービス化の進捗
➡ストアドプロシージャ処理をマイクロサービスに移植しAPIアクセスへ、APIはKubernetes上で動作する。（基本は「Read Only」（以下、RO。）のもの）
➡その上でROトラフィックのマイクロサービス切替が成功し100%の切替成功状態に。なお、ROは廃棄予定。
➡革新と安定のバランス 安全なものなどない 技術の進化・多様性 No Boundary 等
➡ZOZOTOWNのクラウドへの期待は「安定＜革新」であり、不具合やトラブルによる停止は大前提。だからこそ、マルチクラウドで！マルチクラウド環境下では同じ設計思想を環境に合わせて実装する。
➡現状はAzureのAKS（＋SQL Database）、AWSのEKS（＋RDS for SQL Server）を利用しており、GCPはPoCの段階。
クラウドの特性との上手な付き合い方ZOZOTOWN篇 ZOZOテクノロジーズ杉山弘二
・スタートトゥデイ工務店（現ZOZOテクノロジーズ）に入社し現在までインフラをメインに担当している、にも関わらずiOSアプリを20以上リリースしている強者な御方です。
・ZOZOのクラウド移行、リプレースプロジェクトの大目的は「システムの多くがオンプレで動いているのでこれをクラウドに動かす」ということ。
【私】目的が何より大事ですよね・・・・何となくクラウドに移行することほど、運用にしろコストにしろ意味のないことこの上ないです。
・クラウド移行することで［複数リージョンによるDR対応・Kubernetesによるオートスケール＆オートヒーリング］を得られる
・現状は Phase 1 が完了し Phase 2 実践中
・オンプレ or クラウドの比較ではリソース調達やシステム停止への対応、自動化等にフォーカスをあて、メリデメを挙げていました。
【私】岡様のセッションにもあった話ですが「安定＜革新」で走り、クラウドに期待を込めているZOZO様は非常にアグレッシブだなぁと感じました。
・Phase 1 の時点で既にリトライ機構が盛り込まれているが、あくまでもAzure内での話なので Phase 2 の目指すべきところはAzureの大規模障害時にAWSに向かうよう対応する。（現状は「コード実装」で行っているとのこと）
・コスト抑制の為に工夫をしている
➡「Azure SQL Database」では上位モデルでエンドポイント可用性維持の為、1台を「readonly」で利用できる仕組みがある。これを利用すれば Master - Slave 構成も1台料金で可能！
スケールアウトのデメリットをいかにして解決するか？ ZOZOTOWNのAzure SQL Databaseコスト節約術 Part2 - ログミーTech
➡時間帯によってリソースを上手く制御しCore数を変える仕組みを取っている。他にリザーブドインスタンスを利用する手もあるが、制約事項もあるので要検討！
Azure Reserved Virtual Machine Instances | Microsoft Azure
トール・マカベッチによるアンサーソング フルコーラスバージョン@ToruMakabe
ベンダー（マイクロソフト）視点のアンサーということで話が展開しました。
・マイクロサービスの設計パターンは公開されている
➡これに限らずドキュメントを拡充しており、Azureの場合は人の手でやっている。
マイクロサービスの設計パターン | Microsoft Docs
・現状認識として、、
➡ゲートウェイは過渡期
➡サイドカー、アンバサダーは選択肢が多い。ただ、ひとつの基盤技術に縛られないほうが良い。
➡サービスメッシュは有望だが過渡期。実装の変化が激しく、現状では期待できる効果よりも労力やリスクが上回りがち。。
・Azureでのアーキテクチャ例はAWSでもGCPでも同様の考え方ができる。強いフロントエンド／ゲートウェイで玄関をまず固め、サービスを追加していく。
・マイクロソフトとしてはマルチクラウド志向に応えるため「OSSコミュニティの中で作っていく」「インターフェースを抽象化する」を心がけている。
➡前者としては「Packaging & distribution／Scalability & control/／Kubernetes developer tooling」の層に分けてそれぞれに注力している。
➡後者としては抽象化の「１」としてOSSコミュニティで抽象化レイヤーを作っていく。サービスメッシュは実装先行で混乱気味、まずはサービスメッシュが持つべき基本機能を定義し、APIを標準化する必要がある。
➡抽象化の「２」として開発者に指示されているOSSのAzure向けプラグイン開発やコンテンツ拡充を狙う。HashiCorp社との協業が良い例。マイクロソフト社員も開発に参加しているとのこと。
➡抽象化の「３」としてAzureのサービスでOSSや他ベンダ仕様も抽象化する
・フロントエンド集約として「Azure Front Door」が紹介され、Observability標準化として「Azure Monitor」にぶら下がるサービス群の紹介がされた。
Azure Front Door Service | Microsoft Azure
Azure Monitor | Microsoft Azure
・Cloud Nativeを盛り上げる為に
➡差別化はしていくがマルチクラウドはウェルカム！
➡マイクロソフトはコミュニティで作る／つなげるに注力する
➡オープンに盛り上げていく
Ask Us Anything! 登壇者に何でも聞いてみようのコーナー
幾つか気になった質問を個人的目線でピックアップします。
===
Q. 停止時間は減った？
A. まだ、道半ばのため、効果はこれから？
===
Q. コストマネージメントするために何かSaaSなサービスを利用している？
A. Azure Cost Managementを利用することでAzureとAWSのコスト管理を一元化できる。コストマネジメントの標準化は知る限りではない。
===
Q. 監視ツールは何を利用しているか？
A. Datadog／New Relicを利用
Cloud Monitoring as a Service | Datadog
New Relic | デジタルビジネスにリアルタイムなインサイトを提供
===
Q. チームの教育はどうしている？
A. チーム自体は5人のチーム（岡様は指示役）、勉強会を頻繁に行っていて偏りのない状況を作っている。
