価値を届ける技術 #bpstudy

bpstudy 勉強会 技術

スライド

www.slideshare.net

価値

  • 技術ってそれだけだったら意味が無い
  • 日経にとっての価値は情報（記事）

情報を届ける

  • 使いやすい
  • 落ちない
  • 早い/強い

内部的な価値

  • 開発者が楽しい
    • ごちゃごちゃしたコードは✕
  • よる眠れる

  • 技術が伸びる

    • コミュニティをやる

  • 言いたいことは言う

    • 「ぶっちゃけこれクソですよね」とか言う

内製化

  • 既存サービスの内製化

アーキテクチャ

  • サービス指向アーキテクチャ(SOA)
    • 1つのサービスを1サービスとして作る
      • データを残すとかも1つのサービス

SOAの現状

  • 4つの内部サービス
  • 3つの連携サーバ
  • 2つのフロントサーバ

APIゲートウェイ

  • AWSのやつではなく自分達の
  • 認証・権限管理
  • 内部サーバへのプロキシ
    • 外の世界との窓口

  • 既存APIの整形

  • 内部がゴチャついてもOK

  • スケールの単位が柔軟
  • 監視やログ集約が大変

AWS

  • 新しく置き換えていっているものから順に
  • ElasticBeanstalk
  • VPC・内部ELBでちゃんと守る
    • ネットワーク構成に強い人が日経にいるので一緒にやった

開発

Python

  • 日経内部にはPythonな人々がいた
  • 開発しやすい
    • 人によって書き方が違うことがあまりない
  • BePROUDの豊富な実績

Python3

  • Python3のメリット
    • 頻繁に聞かれる
    • 日本語問題の少なさ
    • 5年後も使える

ライブラリの問題は？

  • Python3で問題なし
    • 8ヶ月で軽微なものが2,3件
      • 別にいらないよね
      • 対応してもらった
    • Ansibleなどのローカルの問題はあった

フレームワークはDjango1.8

  • jangoベースのライブラリがかなりある
  • LongTermSupport(3年間)

プロジェクトテンプレート機能

  • まだjangoに詳しくない、ベストプラクティスを知らない人も始められる
  • テストランナーの設定
  • Dockerfileなどの初期設定も詰め込んである

DjangoRestFramework

  • RestAPIが簡単に作れる
    • 最近はAPIと分離して作っていこうという流行がある
  • Djangoの不足機能を補う
    • API自動生成だけでない便利な機能がある

swagger

  • RestAPIをその場で使えるAPI仕様書
  • 関数とかの説明を公開してくれる

運用

Dockerを採用

  • 仕事で使っている人…会場ではまだ2人だけ
    • プロダクトで使うとちょっと…
    • ログの出力場所は？
  • AnsibleでDockerを載せるサーバ構成を作る
  • コンテナでGracefulアップデート

ElasticBeanstalk

  • AWSが提供するPaaS
  • 1インスタンス複数Dockerコンテナ
  • インスタンス毎のオートスケール可能
  • CI連携で開発にデプロイ
  • ElasticBeanstalkはEC2コンテナサービスを内部で使っている

Dockerはログを残すのが大変→fluentで解決

Rundeck

  • バッチ管理サーバ
    • すごいcron
    • 今まではsystemWorkerを使っていた
  • 最近実行したジョブの一覧とかも取れる
  • 中で実行したコンソールも表示できる
  • Jobが失敗した場合にSlackに通知したりもしてる

Sentry

  • アプリケーションログを集約するサーバ
  • 管理・周知してくれる
    • 500系エラー
    • Pythonのロガーからエラーを集約
  • エラー発生→初回のみ通知
    • 秒間500回叩かれたりしても、初回のみ
  • エラーを確認済みにすると、再度通知
  • noteも残せる
  • Githubと連携して、エラーを元にissueが作れる
  • エラーが来るnote作成→GitHub issue作成→対応する→確認完了
  • アプリケーションエラーのトレースバックが取れる
  • 発生時の変数が全て見れる

NewRelic

スキルの習得

  • スキルを盗んでもらう
    • 納得して知ってもらう
  • スキルを一緒に取得する
    • 「教える」ではない
  • 信頼関係を築くのが大事
    • まだ信頼関係がない状態でマサカリを投げるのは良くない

ペアプロ（作業）

  • まだ慣れてない人と作業
    • 一緒にやって一緒に教える
  • モジュール設計で悩ましいときにペアプロ

レビュー

  • PullReqが来たら積極的に見ていく
  • 重要な実装上の問題から
    • 最初から沢山投げると気が滅入る
    • 沢山書くと覚えられない
  • 設計上のアドバイスはその次
  • 書き方などの軽微なコメントは無視しても良い
    • どうしても言いたければ、それを前置きする
    • そういう問題は静的解析で見つける

Wiki

  • Wikiに先にまとめる
  • 書いたWikiを元に伝える
    • 間違えがあったらその場でWikiを直す
    • 言ったことを後でWikiに書くと、それは見られない
  • 読まれない文章に意味は無い

技術の伝え方まとめ

  • 信頼関係を大事にする
  • 情報の重要度も伝える
  • 情報は繰り返し使う

質問

Q. スキルの習得「教えるよりも一緒に学ぶ」とは、日経さんはどれぐらいのスピードで覚えていったのか？覚える過程など

    1. 8ヶ月で、最初の2人のメンバーは技術を探していくフェーズ
  • 新入社員やアルバイトは一緒にやりながら開発していく
  • 半年では、まだきれいな設計・きれいなコードはできない
  • 他の人に支えられながら、一つのサービスを任せる程度

Q. ペアプロをやっている時の自分の作業との配分は？

  • 開発作業1/3、調査1/3、伝える作業が1/3ぐらい

Q. 入れようと思って止めたものは？

  • ECS
    • コンテナのスケールができなかったから
  • ファンクロード
    • 分散して負荷ができなかったから
    • ro-kasutoIOを使っている