unhurried

コンピュータ関連ネタがほとんど、ときどき趣味も…

Developer Summit 2019 Summerまとめ

Developer Summit 2019 Summerで参加したセッション(一部)の概要をまとめた。

大規模レガシー環境に立ち向かう有機的な開発フォーメーション

https://www.slideshare.net/i2key/devsumi-152929762

リソース効率性(稼働率を重視)とフロー効率性(リリースの早さを重視)のいいとこ取りをしたい。

タウンワークでの事例

責務ごとにチームを分け、各チームごとに予算枠を決める。 → 現場裁量で業務を進めることができる。(マイクロサービスからアーキテクチャを除いたイメージ)

  • 商品開発チーム(求人情報機能開発)
  • グロースハックチーム(CVR向上、UI/UX改善)
    • フロー効率(開発サイクルの速さ)重視、アジャイル開発
  • 安定稼働チーム(障害対応/SRE)
    • 組織的ゆとりとして、普段は安定稼働のためのアーキテクチャを含めた改善を行う。
    • 障害発生時は全力で解決に当たる。

ヤフーのアプリにおける会社全体での業務効率化について

Yahoo! JAPANのネイティブアプリは50以上あり、サービスごとに開発チーム(エンジニア、デザイナ)が分かれている。チームの大きさや開発手法もそれぞれ異なるため、サイロ化が課題となっている。

この解決のために、CTO室アプリ統括部という全社横断チームを作った。

  • メンバーはサービス開発と兼務。
  • 黒帯(特定領域の第一任者)も参加し、相談しやすい環境を作る。
  • 開発はペアプロエリアで週4時間(2時間 x 2回)。
横断チームでの取り組み事例
  • 既存のアプリから機能を抜き出して共通ライブラリ化(ログイン処理や、アップデート機能など)
  • 新技術(OSの音声機能対応、機械学習など)の調査・サービスへの取り込み
  • 社内SDKOSS化(サービスの目標に直結しない活動にも取り組みやすい)

実践 Engineering Manager ~理想のエンジニアチームを目指して~

https://speakerdeck.com/_atsushisakai/practice-engineering-manager

家族アルバムサービス「みてね」のマネージャとしての思想と実践について

マネージャがストレスを抱えないようにしていること
  • 目標に対してひとつずつやっていく。
  • できない・わからないことはオープンにする。
  • せっかくなので充実したキャリアになるように意識を持つ。
  • …など
理想のチームとは
  • エンジニアがプロダクトに責任を持ち、ボトムアップで意見・提案を上げられる。
  • 様々な視点で振り返りを行い、失敗や意見の対立を受け入れて学習していける。
エンジニアリングマネージャの役割

エンジニアが働きにくい状況の防止・検知・除去。そのために以下を行っている。

  • 意見が対立したときの対処方法など、最低限のチーム運営ルールを作る。
  • アクション可能なチーム・個人の目標をディスカッションして作る。
  • 定期的な振り返りで成功・失敗を賞賛し、失敗は影響を最小化して改善につなげる。
チーム独自の学習・ボトムアップ文化
  • ユーザーストーリーマッピングを企画とエンジニアが一緒に実施し、要求や課題の理解を深める。
  • バックログの準備会議を行い、エンジニア目線での機能提案を行う。
  • リリース管理(QA進行管理や関連部門との調整など)を輪番制にして、開発工程の影響範囲を認識する。
  • エンジニアがリーダーになり、小さな改善・課題をプロジェクトとして解決する。

ソフトウェアアーキテクチャ組織力

https://speakerdeck.com/hirokidaichi/power-theory-of-software-architecture

アーキテクチャとは何かをしにくくする代わりに、何かをしやすくする構造

例)Web開発フレームワークは、Web開発以外をしにくくする代わりに、Web開発をしやすくする。

→ 社会をとりまく目に見えない力を生み出す構造 = アーキテクチャ

アーキテクチャを構成する様々なパースペクティブ
  • プロジェクト(マネジメント)
    • プロジェクトとプロダクトの依存関係は相似する。
    • ウォーターフォールでは設計フェーズで全てのシステム依存関係を定義するが、アジャイルでは漸進的に改善していく。
  • 組織構造
    • 組織とシステムは同じ構造に変化しやすい。(悪い組織構造 ⇔ 悪いシステム構造)
    • 技術的負債は組織がシステム構造を必要な速度で変える能力を失うこと。
  • ビジネス構造(モデル)
    • ミッション → 戦略 → アクションという目的・手段構造に合わせたシステム構造が望ましい。
    • ビジネスの変動に対してロバストになる。(アクションが変わったときは対応するシステム要素のみ変更すればよい。)

アリババW11を支えるインフラの技術

天猫(B2B向けのECサイト)が11月11日(W11)に開催する巨大セール 2018年の実績:取り扱い高 3.5兆円/日、商品発送 10億件

このセールに対応するために毎年インフラの改善を積み重ねてきた。

  • CDNキャパシティの予測精度向上
  • リソーススケジューラの開発(リソース管理の手順書が2000を超えてきていた)
  • 複数リージョンに跨ったリクエストの分散
  • オンライン処理とバッチ処理のリソース管理統合(リソース融通)
  • ストレージへのアクセスをTCPからRDMAに変更
  • …など

SI × Webの総合力で切り拓く新しいエンジニアのキャリアパス

(株式会社メドレー:オンライン診療アプリCLINICSなどを展開する)

従来はアプローチが異なっていたSI系とWeb系のエンジニアだが、X-Techの登場で両者のスキルの組み合わせが求められるようになってきている。

  • X-Techでは法規制・ガイドラインへの対応や関係省庁との調整が必要となる。
  • このため、Web系のテクニカルスキル(開発スピード、モダン技術)に加えて、SI系のビジネススキル(業務設計、調整)が求められる。
医療系システムでの大変なところ
  • 日本国内法の適用が及ぶ場所に設置する必要がある。
  • 医療機関に対して必須となるクライアント認証
  • レガシーな医療システム(病院内システム)との連携

クラウドネイティブ時代のマルチテナントアーキテクチャとデータ設計

(株式会社エイトレッドクラウドアプリ基盤ALTLED Work Platformを開発)

アーキテクチャ:AngularJS + Java (JAX-RS) + MongoDB / Elasticsearch / Redis

アーキテクチャ詳細(バックエンド)とマルチテナント対応方法
  • APサーバ:ECS(on EC2)
  • MongoDB
    • EC2上に構成(プライマリ1台、レプリカ2台)
    • テーブル名でテナント分離 → 今後はサーバー分離を入れていく
  • Elasticsearch
    • インデックス(RDBでのテーブル)でテナント分離
  • (参考)リクエストのテナント識別
    • セッションにテナントIDを入れている(できればドメインで識別できると楽)
パフォーマンス改善への取り組み
  • Cloud Watch Logs Insightsで現状把握して優先度付けを行う。
  • 処理が重いAPIのみ別のリソースに振り分けて、他の処理に影響を与えないようにする。
  • 予防としてユーザーごとの資源割り当てを決めておくことが大事。(後で変えにくい。)

システム設計の先導者 ITアーキテクトの教科書[改訂版]

https://www.nikkeibp.co.jp/atclpubmkt/book/18/267970/

本書では、システム開発の各ライフサイクルでITアーキテクトのすべきこと(成果物)が、筆者の経験を基に解説されている。要件定義から運用・保守、システム再構築に渡って必要な成果物の作り方が例を交えて説明されているので、網羅的かつ具体的な内容となっている。

本書の元となった日経SYSTEMSの記事が2013年のものであることと、対象がエンタープライズシステムであることから、最近のWebシステムには必ずしも当てはまらないもの(ウォーターフォール開発や、RDBMS前提のデータモデルなど)もあるが、このようなシステムでは本書の成果物の一部のみ作成すれば十分な場合が多いため、十分参考にできる。

オープンソースカンファレンス 2019 Tokyo/Spring まとめ

数年ぶりに参加したので、聴講したセッションの内容をまとめた。

https://www.ospn.jp/osc2019-spring/

(1) OpenSDS,始めてみませんか(BOF

OpenSDSとは

各社のストレージ製品を統一管理するためのソフトウェア(管理のみでデータ送受信は既存のプロトコルを使う。)

Kubernetes CSI (Container Storage Interface) 用のDriverも開発されている。

現在のステータス

開発コミュニティはLinux Foundationがホストしている。EMCやHuaweiに加えて、NTTコミュニケーションズYahoo! Japanといった日本メーカーも参加して開発を進めているが、現在はまだデモができるレベルの完成度となっている。

参考

(2) Ansible・Serverspecベースの自動化のフレームワークSHIFT wareの紹介

SHIFT wareとは

TIS株式会社が開発するインフラ管理自動化のためのオープンソースソフトウェア

https://shift-ware.github.io/ja/

Ansibleの設定ファイルとServerspecのテストコードをExcelから自動出力できる。インフラ管理者が使い慣れているExcelを使うことで、導入時の学習コストを下げられる。

  • Ansible:サーバー構成管理ツール(yamlで設定ファイルを書いていく)
  • Serverspec:サーバーテストツール(Rubyでテストコードを書いていく)

(3) Elastic Stackでマイクロサービス運用を楽にするには?

Elastic Stackとは

Elasticが開発するデータの収集・検索・分析・可視化のためのOSSの組み合わせ

  • Beats
    • 軽量データシッパー
    • パケット、ファイル、各種メトリクスなどを送信する。
  • LogStash
    • データのパースや変換を行う。
  • Elasticsearch
  • Kiabara
    • データを可視化・ダッシュボード機能を提供する。

SaaS版(Elastic Cloud)やオンプレミス版(Elastic Cloud Enterprise)も提供されている。

マイクロサービス運用での活用

Beatsファミリーでマイクロサービスの様々なデータを収集できる。

APM (Application Performance Monitoring) にも対応している。

  • 各アプリケーションフレームワーク用のエージェントを組み込むことで分散トレーシングができる。

その他に、通常時のログから機械学習でモデルを作成し、異常検知を行う機能(有償)もある。

参考

(4) スケールアウト型データベース GridDB

GridDBの概要
データモデル
  • NoSQLで一般的なキーバリュー型とは異なり、行指向に近いキーコンテナ型というデータモデルを採用している。
  • キーバリュー型では各行をキーとバリューの組み合わせで表現するが、キーコンテナ型ではキーに対応するコンテナに行を格納する。
  • 時系列データを扱いやすく、コンテナ内では行単位のACIDトランザクションもサポートされる。
クラスタ構成
  • ノード間でマスターノードを自動的に決定するため、管理ノードが不要で単一障害点がない。
  • ノード間でのデータの偏りが生じないように、データの再配置を自律的に行う。
性能比較
  • 主としてメモリにデータを格納することで高速なアクセスを実現する。
  • Yahoo! Cloud Service BenchamarkではCassandraを上回る性能が出ている。
参考

自動車登録の住所変更手続き

転居したときには自動車登録の変更が必要となるが、警察署と運輸局の両方に出向く必要があり、手続きが複雑になっている。 備忘録として、自分の経験をもとに自動車登録の氏名・住所変更手続きの流れをまとめた。

(1) 自動車保管場所証明を取得する

都道府県の警察署で自動車保管場所証明(車庫証明)を取得する。(申請と証明書受け取りで警察署に2度出向く必要がある。)

準備するもの

  • 自動車保管場所証明申請書
  • 保管場所の所在図・配置図
  • 自動車保管場所使用承諾証明書(もしくは駐車場契約書の写しなど)

※ 申請書は各県警のWebサイトから入手できる。(長野県の場合:長野県警Webサイト

(2) 自動車登録を変更する

運輸局支局で自動車登録内容の変更を申請する。

準備するもの

  • 申請書(第一号様式)
  • 車検証
  • 自動車保管場所証明(発行から1ヵ月以内のもの)
  • 戸籍謄本(発行から3ヵ月以内のもの)

※ 申請書は運輸局のWebサイトからダウンロードできる。

書籍「プロダクションレディサービス」まとめ

UberのSREが可用性の高いマイクロサービスに必要な標準について解説した書籍です。説明されている標準の中から対応できていないサービスが多いと感じたものをまとめました。

qiita.com

ソーシャルアプリプラットフォーム構築技法

立ち寄った書店で見かけて衝動買いした書籍ですが、簡単に感想をまとめました。

自社サービスを社外の開発者に公開するためのプラットフォームを構築するときに必要となる、社内の組織構造や企画・開発・運用について、筆者の経験をもとに解説されています。

最近は多くの企業が他社と連携するためのプラットフォームを開発しており、私も同様のプラットフォーム(筆者のものに比べれば小規模ですが)の開発に携わったことがあります。

構築の際にまず困ることがこれらのプラットフォームの企画・開発・運用に関する情報はあまり公にはされていなく、他社事例の情報が少ないことです。この書籍は開発時のアーキテクチャやデータの設計まで踏み込んで解説されているため、プラットフォームの1つの構築事例としてとても参考になりました。

もちろん書籍で解説されていることが全てのプラットフォームにそのまま適用できるわけではありませんが、これからプラットフォーム構築を検討されている方には事例として役に立つでしょうし、すでにプラットフォームを運用している方にとっては、自分のサービスと比較することで今後の方針検討に活用できると思います。

Pythonではじめる機械学習

Pythonではじめる機械学習を読みましたので、簡単に内容をご紹介します。

Pythonではじめる機械学習 ―scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎

Pythonではじめる機械学習 ―scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎

本書は、機械学習の数学的な理論を概念レベルで理解しつつ、実践で機械学習アルゴリズムを使えるようにすることを目指す書籍である。

sckit-learnで利用できる機械学習アルゴリズムについて、それぞれの特徴と使い方が説明されている。また、実践的なテクニックとして、グリッドサーチを使ったパラメータのチューニングや、前処理を組み合わせてパイプラインを構成する方法についても詳細な解説がある。