O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

アプリエンジニアからクラウド専用のインフラエンジニアになってみて

77.070 visualizações

Publicada em

アプリエンジニアからインフラエンジニアになり、AWSでの構築・運用、Infrastructure as codeを実践した上で苦労した点、そしてインフラ目線から今後アプリエンジニアに期待することや、関係性について思うことを話したいと思います。

Publicada em: Tecnologia
  • Seja o primeiro a comentar

アプリエンジニアからクラウド専用のインフラエンジニアになってみて

  1. 1. アプリエンジニアから クラウド専用の インフラエンジニアになってみて NRIネットコム株式会社 佐藤 瞬 2015/07/24  DevLove関西
  2. 2. 誰? 佐藤 瞬 NRIネットコム株式会社 福島県会津若松市出身 Amazon Web Services 
 パターン別構築・運用ガイド
 書きました
  3. 3. Amazon Web Services パターン別構築・運用ガイド AWS本の中で もっとも分厚い本です
  4. 4. NRIネットコム Webシステムの企画・設計・開発・運用 Webディレクター/デザイナーも多数在籍 NRIグループとして国内複数ヶ所にデータセンター もちろん、AWSはじめクラウドにも力を入れています Web周りのビジネスを専門としている会社
  5. 5. 本日のテーマ クラウド時代のエンジニアの役割
 ∼AWSを使い続けて気づいたこと∼
  6. 6. まずは私の経歴から 1. 基幹システムの運用 POSを担当。レジ作ってました。 2. 証券系Webシステムの開発 ガチガチのウォーターフォール 3. AWS上でシステムの構築・運用 ECサイト、業務システム、キャンペーンサイトなど それなりにアプリやった後 インフラエンジニアにクラスチェンジしました
  7. 7. というわけで、 * アプリ・インフラ両方を経験している * 現在はAWSをがっつり触っている という立場から、今日のテーマについて話していこうと
 思います。
  8. 8. Agenda アプリエンジニアがAWSを触りはじめて感じたこと Infrastructures as codeへの取り組み これからのアプリエンジニアとインフラエンジニアに ついて思うこと
  9. 9. AWSを触りはじめて
  10. 10. 一番はじめに感じたのは 情報量の多さ
  11. 11. 簡単に情報が手に入る 公式ドキュメント
 http://aws.amazon.com/jp/documentation/ Developers.io
 http://dev.classmethod.jp/ ググればSlideShareやQiitaにもたくさん フレームワークやライブラリについて調べるより遥かに楽
  12. 12. AWSサポート 技術的な疑問や課題に答えてくれる ビジネスサポート以上であればチャットができる
 →障害時に助かります 日本人が対応してくれるので余計な心配をせず  コミュニケーションできる 調べてよくわからなくても、サポートに聞けばいい
  13. 13. 詰まったところ
  14. 14. 主にネットワーク周り VPC / Route Table / Internet Gateway / Security Group VPC∼Security Groupなどのネットワーク周りまで AWSを使う前にイメージできてなかった EC2とかRDSは1クリックで立ち上がるもんだと思っ ていた(ゆとり)
 →思いの外、設定項目が多い
  15. 15. よかったところ
  16. 16. プログラマブルに構築できる APIですべて操作できる(はず) SDKが充実
 → 言語がよりどりみどり。好きなものを選べる
 AWS自体が巨大なフレームワークのような感覚 Java Python (boto) PHP .NET Ruby Node.jsJavaScript
  17. 17. ネットワーク∼仮想マシンまでコード化できる AWSがプログラマブルに構築できる Chef/AnsibleなどでOS∼ミドルウェアはコード化できる ネットワーク∼デプロイまでコード化できる デプロイもコード化できる
  18. 18. Infrastructure as codeへの取り組み
  19. 19. Infrastructure as codeへの取り組み コード化の取り組みについて 実際にコード化してみて感じたこと
  20. 20. コード化の種類 AWS構築のコード化 OS∼ミドルウェア構築のコード化 デプロイのコード化 運用のコード化
  21. 21. AWS構築のコード化
  22. 22. AWS構築のコード化 CloudFormation AWSのリソースをJSON形式のtemplateで定義 templateに従って自動構築してくれるサービス AWSリソースのほとんどに対応
 → 対応してないものもたまにある
  23. 23. AWS構築のコード化 CloudFormationの問題 JSONがつらい。 数百行のJSONファイルができあがるので闇が深い JSONはプログラムで使う分にはいいが、
           人間が使うものではない
             (※個人の感想です)
  24. 24. kumogata CloudFormationのテンプレートをRubyで書ける Rubyで書ける意味 コメントが記述できる 同じ処理はループで書ける ファイルを分割できる
 (require、load、includeを使う)
  25. 25. kumogata 詳しくはGithubのリポジトリを
 https://github.com/winebarrel/kumogata Web+DB Press 2015年2 月号
 http://gihyo.jp/magazine/wdpress/archive/2015/vol85 Codenize.tools kumogata以外にもAWSのコード化に便利なツールが
 ってます
 http://codenize.tools/
  26. 26. OS∼ミドルウェア構築のコード化
  27. 27. Chef クライアントが必要 機能が多く、便利な反面複雑 他のメンバーへの教育が大変 Ansible 手軽さと簡単さは素晴らしくいいが、Playbook がYAMLなのはつらい Pythonよく知らない → どっちもしっくりこなかった OS∼ミドルウェア構築のコード化
  28. 28. Itamae ChefとAnsibleのいいとこ取りしたようなもの Rubyで書ける(ChefのようなDSL) クライアント不要(SSH経由で実行可) 覚えることが少ない。すごくシンプル
 → レシピを実行する以外の機能が特にない コア部分はSpecinfra
  29. 29. Itamaeのサンプル 以下が参考になります itamaeのテストコード
 https://github.com/itamae-kitchen/itamae/tree/master/spec/integration/recipes itamae plugin
 Githubで「itamae plugin」で検索
 → ChefのCommunity Cookbookのようなことをgemでやってる
  30. 30. デプロイのコード化
  31. 31. デプロイのコード化 AWS SDK + fabric(Pythonのツールの方) AWSを操作する必要がある部分はSDKでスクリプトを作成 デプロイ前のAMIの取得、EIPの付け替えなど アプリを置いたり、アプリ起動までの準備などはfabricで fabricを使ってる理由はシンプルだから
  32. 32. 運用のコード化
  33. 33. 運用のコード化 バックアップ・監視/通知・障害対応など hubot × Slack(一例) 障害時にAWSコンソールにログインして確認するのは面倒 AWSのAPIをhubotで叩いて情報を取得 主にEC2インスタンスのステータス確認に活躍してます セキュリティの観点からあまり深いことはやらせていない
  34. 34. といった感じでコード化をすすめてきました
  35. 35. Infrastructure as codeを実践してみて インフラのコードを書くこと自体は簡単 問題はどのようにインフラを設計するか 結局、インフラの知識が最も重要 コードを書けることよりも、 インフラの知識がどれだけあるかが重要
  36. 36. Infrastructure as codeを実践してみて プログラマブル ≠ アプリエンジニアの仕事 インフラがプログラマブルに書けるといっても、
 いきなりアプリエンジニアがやるのは難しい 正しくインフラの知識と経験を持った人間が行うべき コード自体がDSLやYAMLなので形式が決まっており、 コードを書いた経験はあまり重要ではない
 → もちろん工夫して書けるに越したことはないですが
  37. 37. Agenda アプリエンジニアがAWSを触りはじめて感じたこと Infrastructures as codeへの取り組み これからのアプリエンジニアとインフラエンジニアに ついて思うこと
  38. 38. これからのアプリエンジニアと インフラエンジニアについて
  39. 39. API Gateway
  40. 40. API Gateway • APIの作成・管理サービス • 実質LambdaにEndpointを持たせることができる • 完全にサーバーレスでサービスが構築可能になる
  41. 41. 個人的には
  42. 42. フロントエンド・モバイルから
 AWS使い放題!!! 超楽しそう!!! IoT とか夢が膨らむね(^^)
  43. 43. という感じでワクワクでしたが
  44. 44. インフラエンジニアの立場で考えると
  45. 45. 構築・運用するインフラがない
  46. 46. 廃業かな?
  47. 47. API Gatewayのインパクト 今までもAWSのマネージドサービスを使って、なるべく サーバレスで構築するのが基本だった それでも中心にはEC2上のアプリケーションがあった
 (BeanstalkもEC2上にアプリがあることは同じ) しかし、API GatewayによってEC2なしでサービスを構築 することが簡単になった サーバレスという方向性は前々からあったが、一気に加速した
  48. 48. 今後のシステム構築 ① まずは、サーバレスで構築する方向で進める
 (フロントエンド / モバイル + API Gateway / Lambda) ② 厳しければ、EC2上にアプリケーションを作る
  49. 49. 今後のシステム構築 ① まずは、サーバレスで構築する方向で進める
 (フロントエンド / モバイル + API Gateway / Lambda) ② 厳しければ、EC2上にアプリケーションを作る ②ではインフラエンジニアにも仕事がある。
  → ①がダメなときにしか仕事がない?
  50. 50. 今後のシステム構築 ① まずは、サーバレスで構築する方向で進める
 (フロントエンド / モバイル + API Gateway / Lambda) ② 厳しければ、EC2上にアプリケーションを作る ②ではインフラエンジニアにも仕事がある。
  → ①がダメなときにしか仕事がない? → ①もやろう
  51. 51. インフラエンジニアの仕事 API Gateway自体、アプリかインフラかで分別はできない 特にインフラエンジニアがやっても問題ない 仕事がくるのを待ってるだけではお荷物
  ※割れ窓理論
    「 建物の窓が壊れているのを放置すると、誰も注意を払っていな いという象徴になり、やがて他の窓もまもなく全て壊される」 https://ja.wikipedia.org/wiki/割れ窓理論 待ってるだけのインフラエンジニア = 割れm(ry
  52. 52. では、アプリエンジニアは?
  53. 53. アプリエンジニアの仕事 当然、アプリエンジニアも①をやる そもそもインフラエンジニアだけでは、ビジネスロジック を完成させるのは難しい インフラエンジニアをアプリエンジニアがサポートしつつ 完成させていく必要がある
  54. 54. あれ? 結局、インフラエンジニアお荷物では?
  55. 55. アプリとインフラの関係 インフラエンジニアも共に行うことで、 EC2上にアプリケーションを構築する必要になった場合、 • なにが問題だったのか • どうやったら解決するのか • アプリケーションにはどのような要件が必要なのか といった現状を把握しているので、すぐに動き出せる。 また、AWSの知識もアプリエンジニアに共有できる。
  56. 56. アプリとインフラの関係 ただし、 実際にはまだまだEC2が必要 ユーザー認証 RDSとの接続 クローズドなネットワーク
  57. 57. 最近の私 でも、素振りはしときましょう フロントエンドの勉強はじめました AngularJS、SemanticUI やっぱりAPI Gatewayと相性がいい
 S3(WebSiteHosting) + API Gateway + Lambda + DynamoDB
 で簡単なアプリを構築中 インフラとフロントエンドが隣り合う技術になった
  58. 58. 最後に 本日お話した内容は、あくまで個人の見解です 正直、どうなるかはわからないし、 廃業の危機はやっぱりありますが、 学ぶことは尽きないので楽しんでいきましょう
  59. 59. ご静聴ありがとうございました

×