【日本語版】Styler: Our Journey to GCP
- 1. Our Journey to GCP
- 2. Who are we?
- 3. Future Shopping Experience Web iOS Android
- 4. 近くの店に からアクセス
- 5. アイテムについて で知る
- 6. でショッピングを楽しむ
- 7. でお店とつながる
- 8. ● 7名のエンジニア ○ 1x iOS ○ 1x Android / Vue.js ○ 2x Vue.js (一人リモート） ○ 3x バックエンド (移行時には２名) ● デザイナー x1 ● 他の部署には３０名以上のメンバー team
- 9. 移行するにあたってのモチベーション ● モノリシックなアーキテクチャ ● バグの原因特定と解決の難しさ ● 開発環境ではDocker を利用していたが商用はコンテナ化されていなかった ● Kubernetes へのチーム全体の興味 ● 技術の進化によるチーム文化の変化 ● 未来に向けた考え
- 10. FACY 移行前アーキテクチャ EC2 Instances ● Nginx ● Rails + Vue.js
- 11. なぜGCP を選んだのか ● クラウドネイティブ時代のパートナーとしてのGoogle ● 絶え間ない進化：Google API の活用 ● 他Google サービスの適用 ● Google データポータル（旧 データスタジオ）の非エンジニアでの利用 ● 素晴らしいドキュメントと手頃なサポートプラン
- 13. モノリシック アーキテクチャ メリット ● （多くの場合）普通に動く ● １つの場所にコードがある ● 開発者が慣れている ● インフラの保守が簡単 デメリット ● 新しい開発者には理解が難しい ● 密結合し、”おまじない”が多くデバッ グが難しい ● デプロイがリスキーになりうる ● 大きな変更時にはよく全体のメンテ ナンスが必要になる Assessment
- 14. マイクロサービス アーキテクチャ メリット ● 一度の実装で、再利用可能 ● サービスレベルでのモジュール化： 少ない”おまじない”とデバッグのし やすさ ● スケールの簡易化と高い冗長性 ● ランニング コスト削減 デメリット ● イニシャル コストが高い：誰もGCP に慣れていなかった ● イニシャル コストが高い：コードの書 き直し ● 分散サービスにはこれまでとは違う 管理手法が必要 Assessment
- 15. 短期的な移行ゴール ● 技術的負債とバグの軽減 ● デプロイを安全で簡単にする ● 長期的なコスト削減 ● 監視精度の向上 ● フォールト トレラント（耐障害性）の改善 ● 何かおかしいときのサポート体制 Assessment
- 16. どうやって短期的な移行ゴールを達成したのか ● Kubernetes（GKE）の利用 ● Infrastructure as code： Kustomize を Declarative Configuration で利用 ● Stackdriver Logging 上でのアラート、ダッシュボードの活用 ● Google のカスタマー エンジニアとのディスカッション ● Google のサポート契約 Detailed Planning
- 18. 移行アプローチの検討 ● リフト＆シフト ● リビルド（再構築） ● 移行してモダナイズ https://cloud.google.com/migrate Detailed Planning
- 19. 長期的な移行ゴール ● コード自体を簡単に理解でき、利用可能なカタチにすること ● アプリケーション内で問題のあるパーツを分離すること ● 新しい開発部分はサービスに焦点をあてたアプローチを取れること Detailed Planning
- 20. 長期的な移行ゴールの達成方法 ● 依存性を軽減するために、既存コードをモジュール化 ● 新規開発時に素早くデプロイを可能にするためにマイクロサービス テンプレートを 開発 ● 新規サービスのためにCloud Endpoints を利用 ● OpenAPI 仕様：開発者が開発ポータル上で仕様の確認とテストができる ● Firebase Authentication の採用 ● メッセージング、イベントの取り込み、配信としてCloud Pub/Sub の活用 Detailed Planning
- 21. GCP Services ... ... ... Legacy App facy.jp アーキテクチャの ゴー ル Cloud SQL Proxy Logging Agent Stackdriver Cloud Storage /new_api_1 Cloud Pub/Sub Cloud SQL Cloud Memorystore New Cloud Endpoints / ESP (例） api.facy.jp /new_api_2 /new_api_3 Example Backend Service 1 Example Backend Service 2 Cloud Load Balancer Cloud CDN Cloud Armor TLS Certificate Cloud Functions Detailed Planning
- 23. 請求についての便利ポイント ● 細分化するために異なるプロジェクト別に設定する ● 設定はサービス アカウントとロールベースのアクセス構成について考える ● 予算設定とアラート設定を行う その他のポイント: ○ Pub/Sub を予算アラートとCloud Functions 用に活用 ○ Slack とのアラート連携 ○ 請求書支払いはGoogle のパートナー経由で可能 Acclimatise & Configure
- 24. k8s Overview - GKE への移行 ● 設定ファイルの管理ツールの検討 (Kustomize, ...) ● GCP プロダクトの選定と作成 (Postgres, Redis, ...) ● GKE Secrets の設計と作成 ● 各種アプリケーションの設計 (Cloud Load Balancer / Ingress, Rails, Nginx, Cloud SQL Proxy, Cron jobs...) ● 設定ファイルの作成および検証 - ローカル環境 (Minikube) or リモート環境 Acclimatise & Configure
- 25. k8s Kustomize を利用した設定ファイルの管理 ● Jsonnet 同様テンプレート記述言語 … さらに、YAML 設定ファイルを他の形式に変換することが可能 ● Kustomize (native support in kubectl from 1.14) ● Template-free, declarative (宣言型) ● ドキュメントが豊富 kustomize.io kubectl.docs.kubernetes.io Acclimatise & Configure
- 28. k8s まとめ ● Kustomize では宣言的な設定ファイルの定義が可能 ● Label と Selector が Kubernetes 利用において肝心なため注意して設計する必要 がある ● Deployment を Selector で切り替える ● クラスタの使用状況測定はクラスタの詳細な利用状況を BigQuery に取り出すこと が可能 Acclimatise & Configure
- 30. アドバイス、フィードバック、レビュー ● Google のカスタマー エンジニアと営業とのミーティング ● コミュニケーション方法の確保（質問＆フィードバック） ● 進捗や質問を確認するためのチームミーティングを毎週開催 ● GCP のサポートプランの活用 Advice, Feedback & Review
- 33. 問題の発見は 早めに！
- 34. Stackdriver Error Reporting Testing / Monitoring / Tweaks
- 35. Stackdriver Error Reporting Image from Google Cloud Documentation Testing / Monitoring / Tweaks
- 36. Stackdriver Error Reporting Image from Google Cloud Documentation Testing / Monitoring / Tweaks
- 37. Stackdriver Viewing Logs Image from Google Cloud Documentation Testing / Monitoring / Tweaks
- 38. Stackdriver Dashboards Round Trip (Total) Latency Response by HTTP Status Testing / Monitoring / Tweaks
- 39. Stackdriver Tips ● Error Reporting はStackdriver Logging に統合されているので、シームレスなデ バッグが可能に。リアルタイムレポートも使いやすい。 ● Stackdriver のログはリソース別、ネームスペース別、セレクタ別でフィルター可能 ● ダッシュボード上の指標を使ってアラートの設定が可能 （メールやSlack などにも通知可能） Testing / Monitoring / Tweaks
- 41. まとめ ● アーキテクチャ含め、ゴールを移行に際して定めることはとても意義があった ● どの程度マイクロサービスが移行の目標に影響を与えたのかは考えている ● 少ないリソースの中で、ハイブリット アプローチ（移行してモダナイズ型）は私たちが重要だと思っている 部分に集中して移行することを可能にしたと考えている ● 移行時にはGCP のサポート パッケージとして開発環境用のプランを最低限契約していることをおすすめ ● 予算機能とアラート機能は、コストを監視する上で便利 ● ネームスペース、ラベル、セレクタは Kubernetes のインフラを考える上で重要だった ● Stackdriverはデバッグと エラーを監視するための非常に貴重なツール
- 42. 使えるリソース ● GCP in Four Words or Less http://bit.ly/2H7y8qs ● github.com/GoogleContainerTools ● Map AWS services to GCP products http://bit.ly/2YgigYG ● cloud.google.com/migrate ● https://kustomize.io/