SlideShare a Scribd company logo
Submit Search
Upload
真っ当な技術を使ったふつうのWebサービス開発
Report
Share
Shota Nozaki
Follow
•
4 likes
•
1,345 views
1
of
26
真っ当な技術を使ったふつうのWebサービス開発
•
4 likes
•
1,345 views
Report
Share
Download Now
Download to read offline
Software
ログミーTech Live #2「レガシーシステムのリニューアル」公園資料
Read more
Shota Nozaki
Follow
Recommended
Yii紹介 by
Yii紹介
ngi group.
1.2K views
•
9 slides
3流プログラマーから見たPhalconとWISP by
3流プログラマーから見たPhalconとWISP
YamaYamamoto
6.3K views
•
47 slides
PHP最速フレームワークPhalconの紹介 by
PHP最速フレームワークPhalconの紹介
Yuji Iwai
5.8K views
•
15 slides
Redmine本家コピー+投票サイト作成(Python-Redmine利用事例) by
Redmine本家コピー+投票サイト作成(Python-Redmine利用事例)
Yuuki Nara
2.8K views
•
30 slides
スクリプト言語PHP攻略法 by
スクリプト言語PHP攻略法
Rui Hirokawa
5.4K views
•
45 slides
PhpStormで始める快適なWebアプリケーション開発 #phpcon2013 by
PhpStormで始める快適なWebアプリケーション開発 #phpcon2013
晃 遠山
19.3K views
•
51 slides
More Related Content
Similar to 真っ当な技術を使ったふつうのWebサービス開発
Ruby で ffmpeg の filter_complex と戯れる話 by
Ruby で ffmpeg の filter_complex と戯れる話
Yoshikazu Kawashima
96 views
•
30 slides
ユーザ・デザイナーから見たPlone CMSのアピールポイント by
ユーザ・デザイナーから見たPlone CMSのアピールポイント
Masaki NIWA
926 views
•
41 slides
PHP Now and Then 2012 at PHP Conference 2012, Tokyo Japan (in japanese) by
PHP Now and Then 2012 at PHP Conference 2012, Tokyo Japan (in japanese)
Rui Hirokawa
2.9K views
•
26 slides
20190427 global azurebootcamp by
20190427 global azurebootcamp
Tomoyuki Obi
622 views
•
26 slides
GitHubで見つかるFileMaker関連ソフトウェア by
GitHubで見つかるFileMaker関連ソフトウェア
Atsushi Matsuo
1.5K views
•
14 slides
NAO/Pepper 開発環境 について by
NAO/Pepper 開発環境 について
Takuji Kawata
3.1K views
•
15 slides
Similar to 真っ当な技術を使ったふつうのWebサービス開発
(20)
Ruby で ffmpeg の filter_complex と戯れる話 by Yoshikazu Kawashima
Ruby で ffmpeg の filter_complex と戯れる話
Yoshikazu Kawashima
•
96 views
ユーザ・デザイナーから見たPlone CMSのアピールポイント by Masaki NIWA
ユーザ・デザイナーから見たPlone CMSのアピールポイント
Masaki NIWA
•
926 views
PHP Now and Then 2012 at PHP Conference 2012, Tokyo Japan (in japanese) by Rui Hirokawa
PHP Now and Then 2012 at PHP Conference 2012, Tokyo Japan (in japanese)
Rui Hirokawa
•
2.9K views
20190427 global azurebootcamp by Tomoyuki Obi
20190427 global azurebootcamp
Tomoyuki Obi
•
622 views
GitHubで見つかるFileMaker関連ソフトウェア by Atsushi Matsuo
GitHubで見つかるFileMaker関連ソフトウェア
Atsushi Matsuo
•
1.5K views
NAO/Pepper 開発環境 について by Takuji Kawata
NAO/Pepper 開発環境 について
Takuji Kawata
•
3.1K views
20090415 すばらしきSymfonyの世界へようこそ by Hiromu Shioya
20090415 すばらしきSymfonyの世界へようこそ
Hiromu Shioya
•
824 views
最強のPHP統合開発環境 PHPStorm by 晃 遠山
最強のPHP統合開発環境 PHPStorm
晃 遠山
•
12.3K views
ゼロからのプログラミングRails講座 Codeanywhere版 by DIVE INTO CODE Corp.
ゼロからのプログラミングRails講座 Codeanywhere版
DIVE INTO CODE Corp.
•
10.7K views
CakePHP PHP Framework by ryota ichie
CakePHP PHP Framework
ryota ichie
•
4.3K views
Php development efficiency improvement by 伸幸 茂木
Php development efficiency improvement
伸幸 茂木
•
290 views
Ruby向け帳票ソリューション「ThinReports」の開発で知るOSSの威力 by ThinReports
Ruby向け帳票ソリューション「ThinReports」の開発で知るOSSの威力
ThinReports
•
6.6K views
コンテナーによるIT基盤変革 - IT infrastructure transformation - by 日本ヒューレット・パッカード株式会社
コンテナーによるIT基盤変革 - IT infrastructure transformation -
日本ヒューレット・パッカード株式会社
•
641 views
技術選択とアーキテクトの役割 by Toru Yamaguchi
技術選択とアーキテクトの役割
Toru Yamaguchi
•
42K views
Web is the OS (Firefox OS) by dynamis
Web is the OS (Firefox OS)
dynamis
•
11K views
5分でわかるphalcon php by Yusaku Kinoshita
5分でわかるphalcon php
Yusaku Kinoshita
•
4K views
5分でわかるPhalconPHP by Shohei Tai
5分でわかるPhalconPHP
Shohei Tai
•
1.8K views
KLab Social Game Platform ~Symfony1.4活用事例~ by KLab株式会社
KLab Social Game Platform ~Symfony1.4活用事例~
KLab株式会社
•
11.1K views
Flumeを活用したAmebaにおける大規模ログ収集システム by Satoshi Iijima
Flumeを活用したAmebaにおける大規模ログ収集システム
Satoshi Iijima
•
20.6K views
FuelPHP活用事例 by Yusuke Naka
FuelPHP活用事例
Yusuke Naka
•
3.3K views
真っ当な技術を使ったふつうのWebサービス開発
1.
真っ当な技術を使ったふつうの Webサービス開発 ログミー株式会社 / 野崎翔太 1
/ 26
2.
野崎翔太 / @emonkak Vimmer
/ Haskeller ログミー唯一のエンジニア OSS Feedpon - LDRライクなフィードリーダー emonkak/php-di - 高速なDIフレームワーク emonkak/php-orm - object-mapperスタイルの軽量ORM emonkak/php-enumerable - LINQ to ObjectsのPHP移植 自己紹介 2 / 26
3.
世界をログする書き起こしメディア ログミー:IT、スタートアップ関係のイベントの書き起こし ログミーTech:エンジニア勉強会の書き起こし ログミーファイナンス:決算説明会の書き起こし ログミーについて 3 / 26
4.
WordPressで独自にテーマ、プラグインを開発して運用 開発・運用・デザインは社外に依頼 現在はログミーファインスについてのみこの旧システムで動作 リニューアル以前のシステム 4 / 26
5.
極度にグローバル変数に依存した設計 テンプレート主体の設計でView以外のロジックを書くべき場所がない とにかく遅い、キャッシュが必須 平均レスポンスタイムが約2000msだったことも(今は約400msまでは 改善) WordPressのつらみ 5 / 26
6.
開発者主導で仕様はほぼなし WordPressから必要な機能だけを抽出してLaravelで再実装 技術的な課題の解決を優先、ビジネスサイドの要望は後回し しかし新ためてヒアリングしてみると、同じシステムを再発明する意義 は薄かった 一度目のリニューアル 6 / 26
7.
開発の内製化 ドメイン駆動設計の導入 ユビキタス言語定義してそこからドメインモデルを構築 開発体制の変更 7 / 26
8.
基本的にシステム上での業務に関しては記事を作成して公開するという 単純なもの しかしログミーには独自の概念「シリーズ」があった 「シリーズ」は日本語で言う「連載」という続きもの記事の集合、とい うのは正確ではなかった 「シリーズ」は親子関係を持つことができる 親子関係は多いものでも3代まで 3代というのが理解の鍵に ドメインモデルの構築 8 / 26
9.
三代のそれぞれの「シリーズ」は役割が違っていた 異なる概念を同じ「シリーズ」という言葉でまとめて親子関係にしてい た 親シリーズ:イベントの主催者(コミュニティ) 子シリーズ:コニュニティによって開催されたイベント(イベント) 孫シリーズ:イベントで行なわれたセッションを記録した記事の集 合(ログ) ドメイン知識の蒸留 9 / 26
10.
リニューアルするサービスは売り上げが立っている 売り上げが立っているサービスは継続可能性が高い 長期間の保守に耐えられる設計が必要 一方、売れるかわからない新規のサービスはスピードが重要 リニューアルのための技術設計 10 / 26
11.
真っ当な技術・実装を選択する 標準化・規格化された技術 デファクトスタンダートの技術 捨てられる実装 真っ当な技術≠枯れた技術 有用な枯れた技術はあまりない 保守性を担保するための技術選択 11 / 26
12.
バックエンドの構成 12 / 26
13.
構成技術 PHP(FastCGI) nginx MySQL memcached crond モノリシックシステム 今後はレコメンド処理をマイクロサービス化を予定 バックエンドの構成 13 / 26
14.
PHP-FIG(PHP Framework Interop
Group)という組織が出している PSR(PHP Standard Recommendation)という標準勧告がある Javaで言う所のJSR(Java Specification Request) PSRはPHPコミュニティでかなりの影響力がある HTTPサーバーのインターフェイスを定義したPSR-15(HTTP Server Request Handlers)がある PHPにおける標準化 14 / 26
15.
interface RequestHandlerInterface { public
function handle( ServerRequestInterface $request ): ResponseInterface; } interface MiddlewareInterface { public function process( ServerRequestInterface $request, RequestHandlerInterface $handler ): ResponseInterface; } PSR-15のインターフェイス 15 / 26
16.
Webフレームワークは使わずにPSR-15に準拠した形でアプリを実装 フルスタックのWebフレームワークは便利だが最新版に追従するのが 大変 ルーティングはTrie木を利用した独自の仕組みをPSR-15のミドルウェ アとして実装 emonkak/routerを利用 パスを/区切リにして木を構築してキャッシュ それに対してマッチングをかけることで高速なルーティングを実現 PSR-11(Container interface)のDIコンテナのインターフェイスも利用 実装としては依存グラフを丸ごとキャッシュすることでが高速なイ ンスタンス化ができるemonkak/diを利用 Frameworkless PHP 16
/ 26
17.
JavaのPersistence API(JPA)のような永続化に関するPSRはない Object-MapperスタイルのシンプルなORM emonkak/orm
を独自開 発 Entityはプレーンなオブジェクトとして定義可能 このORMに依存するのはRepositoryの実装のみ 永続化とORM 17 / 26
18.
public function articleOfId(ArticleId
$articleId): ?Article { return $this->grammer ->getSelect() ->with(Relations::oneToOne( 'eye_catch', 'images', 'eye_catch_id', 'image_id', $this->pdo, new ObjectFetcher(Image::class), $this->grammer->getSelect() )) ->from('articles') ->where('articles.article_id', '=', $articleId->getId()) ->getResult($this->pdo, new ObjectFetcher(Article::class)) ->firstOrDefault(); } Repositoryの実装 18 / 26
19.
ユーザーにはドメインモデルで表現される形とは違う見せ方をしたい場 合がある CQRS(Command Query Responsibility
Segregation)の考え方を活 用してコマンドモデルとクエリモデルに分ける データの更新を対応するコマンドモデルはドメイン知識を反映したドメ インモデル データの読取を対応するクエリモデルをプレゼンテーション用のモデル として新たに実装 実装としてはアプリケーション層に FooData、FooQueryService と いう名称で作成 これはドメイン層における Entity と Repository の関係と一緒 CQRSの活用 19 / 26
20.
フロントエンドの構成 20 / 26
21.
ビルドツール Webpack Babel TypeScript MPA(Multi Page Application) フロントエンドの構成 21
/ 26
22.
jQueryの時代はこんなコードを各所に書いていました $('#js-button').on('click', function() { ... }); コンポーネント単位での再利用が難しい 要素とJSのコードが離れてしまっていて管理が難しい Reactなら
ReactDOM.render() をどこに書くべきかとう問題が生じ る JSのブートストラップをどこでやる か問題 22 / 26
23.
Web Componentsはカスタム要素(タグ)を作るためのAPI群 モダンブラウザはネイティブサポート IE11はPolyfill必須 Custom Elementのみ使用 Shadow
DOMは使わない HTMLElementを継承したComponent実装のための基底クラス StatefulComponentを作成 ReactライクコンポーネントAPI テンプレートの描画にはlit-htmlを利用 コンポーネント間のメッセージングにはCustomEventを活用 全部で400行程度のコンパクトな実装 WebComponents + lit-html 23 / 26
24.
インフラ構成 24 / 26
25.
Pull RDS(MySQL) ECS Service(Fargate) S3 Cloudflare Application Load
balancer App Container (PHP-FPM) ElastiCache (Memcached) Proxy Container (nginx) Scheduler Container (PHP+crond) CodePipeline Push GitHub CodeBuild Deploy Lambda ECR インフラ構成 25 / 26
26.
リニューアルするサービスは継続可能性が高いので保守性を重視して開 発 サーバーサイドはPSRの標準化技術を使って、フルスタックのフレーム ワークの利用を避けた フロントエンドはブラウザの組込みの機能であるWebComponentsと lit-htmlを使ってコンポーネントを実装 インフラはコンテナ技術とデプロイの自動化をすることで運用コストを 削減 長文を掲載するメディアなので読み易くなるようなUIデザイン まとめ 26 / 26