Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AWS & Google Cloud 両方を駆使するチームでの技術選定

AWSとGoogle Cloudを両方使いながら技術選定とそのあとの保守について、気にかけていることを、ざっくりまとめました

  • Be the first to comment

  • Be the first to like this

AWS & Google Cloud 両方を駆使するチームでの技術選定

  1. 1. AWS & Google Cloud 両⽅を駆使するチームでの技術選定 アイレット株式会社 ⾼橋修⼀
  2. 2. ⾃⼰紹介:⾼橋 修⼀ 所属: アイレット株式会社 MSP開発セクション@⼤阪 属性:開発エンジニア・プログラマ 役割:グループリーダー クラウド: AWS: 2020APN AWS Top Engineers、All certificates Google Cloud: 5 certificates
  3. 3. 技術選定の背景 =私のポジション
  4. 4. AWSプレミアコンサルティングパートナー Google Cloudプレミアサービスパートナー クラウド導⼊実績2,000社以上、年間プロジェクト3,200以上
  5. 5. 構築・2次運用 お客様 MSP運用 お客様環境 MSP社内サービス (サービス数:18) MSP開発 利用・操作認証 情報取得・操作 利用 依頼・要望・FB ヒアリング・提案 開発・運用保守 構築・監視運用保守 ここ MSP開発 課題管理 外部サービス
  6. 6. 技術選定の話 以降、個⼈の⾒解!
  7. 7. 基本的な考え できるだけマネージドなものを使う ・AWSであればEC2よりもFargateやLambdaなど。 ・Google CloudであればGCEよりもCloud Run、Cloud Functionsなど。 3rdのSaaSやソフトも活⽤ ・New Relic、PagerDuty、Slack、Twilio、Terraformなどなど →こちらで担保すべき範囲を減らし、開発の⾼速化↑/保守コストの低下↓ etc.
  8. 8. 3rdの活⽤ メインのアーキテクチャは AWS、Google Cloudのサービスで構成 デプロイや監視・モニタリングなどは 3rdを活⽤することが多くなってきた デプロイ 監視 テスト
  9. 9. クラウドベンダーサービス or 3rd AWS Google Cloud 3rd CI/CD Code Pipeline Code Build Code Deploy Cloud Build Circle CI Travis CI GitHub Actions IaC Cloud Formation SAM CDK Deployment Manager Terraform severless 監視・モニタリング Cloud Watch X-Ray Cloud Monitoring Cloud Trace Cloud Profiler New Relic Datadog Mackerel 例 これらを組み合わせて利用することも可能 例) CI/CDでパイプラインはCircle CIを使い、デプロイはCode Deployを呼び出す
  10. 10. クラウドベンダーサービス or 3rd 3rdのメリット • AWSでもGoogle Cloudでも、同じ⽅法で対応できる。 • 習得コストが低く抑えられ、保守体勢も組みやすい • (個⼈的に)機能が豊富、痒いところに⼿が届く。
  11. 11. クラウドベンダーサービス or 3rd クラウドベンダーサービスのメリット • クラウド内のサービス連携が強い • 権限やユーザーの管理がIAMで完結 • 別途キーの管理やユーザー管理を考えなくていい • 利⽤料⾦がクラウドサービス内で完結する • 別途プラン選択や料⾦管理を考えなくていい
  12. 12. できないことの確認 どのサービスを使うにしても「制限/上限」は確認する。 その「上限」が引き上げリクエストができるタイプものかも確認。 例 ・FaaSの同実⾏可能数 ・作成できるリソース数上限 ・性能(受けられるリクエストレート)
  13. 13. ベストプラクティス お役⽴ち情報
  14. 14. ベストプラクティス Well-Architected ツール • ベストプラクティスに沿っているか⾃⼰診断するチェックリスト • 「運⽤」「セキュリティ」「信頼性」「パフォーマンス」「コスト最 適化」の5つの観点
  15. 15. ベストプラクティス ソリューション デザインパターン • https://events.withgoogle.com/solution-design-pattern/ • ワークフローごとにアーキテクチャの解説 • 「注意事項」や「向かないケース」も載っている
  16. 16. いろいろ使う上で考慮していること • チームとして保守していけそうか • 作業環境の再現性 • 作業環境もリポジトリにDockerfileで定義 • 選定理由を残しておく★ • EOLやアップデート追従への管理★
  17. 17. 選定理由を残しておく • 設計資料として残す • Wikiにディシジョンレコード • Slackのpublicな独り⾔チャンネルに垂れ流し • 他の⼈の発⾔を検索でひっかけ役⽴つこともあるのでpublicで!
  18. 18. EOLやアップデート追従の管理 ⾔語やフレームワークのサポート期限、推奨APIバージョンの変更など 計画的に対応する必要がある。 現状:スプレッドシートで⼀覧にし、⽉1定期で対象や状況を⾒直し。 という泥臭い⽅法でやってます。「こんな感じでやってるよ〜」とかあればコメントもら えると助かります!
  19. 19. ご清聴ありがとうございました

×