kの値はヒューリスティックに決定される。おいて、書き込みスループットとデータ保持の観点で、3種類のKVSによる費用最適化が可能であることを確認する。サンプルとして、100,000データポイント/sの書き込みスループットにおける費用比較を以下の表に示す。2018/05/05時点のap-northeast-1リージョンのオンデマンド費用を元にしている。1258848.00RedisはEC2インスタンスのr4.large(0.176USD/時間)を使用し、各パーティションあたりのレプリカ数を2、つまり3ノード/パーティションとする。1ノードあたりの書き込み上限を25,000reqs/secとする(要出典)。したがって、r4.largeインスタンスが12台必要となる。EC2インスタンス上のRedisは、書き込み元のwriterと異なるアベイラビリティゾーンに配置されている場合、別途GBあたりのゾーン間転送料金が発生する。DynamoDBの料金構造21からアイテムサイズに比例してI/Oコストが大きくなる。今回は、最低単位の1KBで計算する。S3は、標準ストレージを利用するもとすると、S3のPUT料金は1000リクエストあたり0.0047USDである。S3はKVSではあるが、ファイルを格納するためのオブジェクトストレージであるため、高スループットかつ小さな書き込みには向いておらず、今回のワークロードでは上表のように高額な料金となる。次に、データ保持費用における費用比較を以下の表に示す。0.025r4.largeのRAMのサイズは16GBであり、GB単価は7.32USD/月、レプリカ数を2とすると上表の値となる。S3は標準ストレージを利用するものとする。以上より、I/O費用とデータ保持費用はトレードオフの関係にあり、高スループット書き込みをインメモリKVSで受け付け、蓄積したメトリックを低速なディスク指向KVSへ移動させる手法の有効性を確認できた。考察と今後の課題Diamondの欠点Diamondは、アーキテクチャレベルで以下の欠点をもつ。ついては、アーキテクチャの章の概要で述べたように、他の要件の達成により欠点を補えると考えている。ついては、シンプルなKVSで表現できる時系列データ構造やインデックス構造の限界がどこにあるかを調査する必要がある。ついては、分散トレーシングなどの分散システムをモニタリングする技術の発達により、補えると考えている。実装レベルでは、以下の欠点がある。データ位置の解決がヒューリスティックであり、データを正しいKVSから取得できることを完全には保証できない(1)については、通常の書き込み経路とは異なる、過去の時系列データをまとめたファイルをバッチでアップロードする書き込み経路を実装することで解決できる。(2)については、静的解決ではなくフォールバック方式またはインデックス方式による動的解決を考えている。フォールバック方式とは、インメモリKVS、SSDベースKVS、HDDベースKVSの順にメトリック系列を参照することである。タイムスタンプレンジの開始時刻のデータポイントが存在すれば、その時点でフォールバックを停止し、応答を返却する。存在しなければ、引き続きフォールバックする。欠点として、静的解決と比較して、低速なKVSに応答速度を律速されやすい可能性がある。インデックス方式は、メトリック名とタイムスタンプレンジを入力として、該当するKVSを返却するインデックスにより動的解決することである。インデックスはインメモリKVS上に保持しておき、データ移動が発生するたびに、インデックスを更新する。欠点として、インデックス分のメモリ使用とI/Oが増加することがある。将来機能Diamondの時系列データモデルとして、現在のWhisperモデルに加えて、Prometheus22が提供するようなラベルによる多次元データモデルをサポートを考える。前者の多次元データモデルの例を以下に示す。instance=”10.0.0.2:80”}メトリック名であるrequests_totalと、ラベルと呼ばれるキーバリューペアの組み合わせにより、メトリック系列を表現する。Prometheusでは、V2ストレージではLevelDBによりラベルに対するインデックスを作成しており、V3ストレージでは転置インデックスに置き換えている23。Prometheusのストレージはファイルシステム上に実装されている一方で、DiamondではKVS上に実装する必要がある。そこで、V3ストレージエンジン同様に、次のように転置インデックスをKVS上に実装することを考えている。メトリック系列にユニークなIDを割り当て、データポイントを書き込むデータポイントに紐づくラベルのキーペアをキー、ラベルに紐づくメトリックIDをバリューとして、別途用意したインデックス用KVSに書き込む。参照時には、ラベルを入力として、メトリックIDを転置インデックスから取得し、メトリックIDをキーとして各KVSからデータポイント列を取得する。実現する時系列データベースアーキテクチャを提案し、実装を示した。アーキテクチャの要点は、複数のKVSを組み合わせたヘテロジニアス構成、メッセージブローカーによるWALリプレイ、サーバレスアーキテクチャおよびべき等性とデータ幅を制御可能なデータ構造である。考察では、アーキテクチャと実装のそれぞれの欠点と解決策、さらに多次元データ構造のサポートのアイデアを議論した。今後の課題としては、以下の2点について、実験・調査したいと考えている。アーキテクチャ要件の(a)、(b)、(c)の有効性を示すために、先行実装であるGraphiteと比較実験する。次に、アーキテクチャ要件の(d)、(e)の有効性を示すための文献を調査する。ソフトウェア開発論文のサーベイにより開発容易性やOSS実装の複雑性を示すヒントを発見する。スライドあとがき@hirolovesbeerさんからの「ヘテロジニアス(heterogeneous)に込めた意味はなにか?」という質問に対してうまく答えられなかったが、この問いの答えがもともとあとがきで書こうと思っていたことだということに気づいたので、ここに記しておく。ヘテロジニアスの対義語として、ホモジニアス(homogeneous)があり、ホモジニアスな時系列データベースとはここではDBMSの実装を一つだけ使ったものを指す。それに対して、ここでのヘテロジニアスとは、異種混合データベースの上にデータベースエンジンを実装することを指しており、ヘテロジニアスであることがDiamondアーキテクチャのアイデアの要点となる。Systemsにて、データシステムを構築する上で、すべての異なる状況に適した1つのソフトウェアは存在せず、異なるソフトウェアを組み合わせアプリケーションを開発していく必要があるという趣旨の意見が書かれている。Diamondアーキテクチャは、この考え方の延長線上にあり、インデックス、WAL、メモリ上のデータ構造、ディスク上のデータ構造など、古典的なデータベースエンジンの構成要素を、ヘテロジニアス環境で再構築したものになる。サーバレスアーキテクチャにより、分散システム上での複数箇所にまたがるデータの更新、移動を、信頼性のあるビルディングブロックの上に構築しやすくなった。実際に、ヘテロジニアスKVS環境でGraphiteを実装したもになるため、今度はヘテロジニアスKVS環境でPrometheusを実装することを考えるといろいろとアイデアがでてくる。さんの言葉を引用する。https://speakerdeck.com/matsumoto_r/rcon-and-capcon-internals-number-lxcjpこの言葉を、分散システム上でOSの構成要素を再構築していくということだと理解しており、これをデータベースに置き換えたような話をやろうとしている気がしてきている。“はてな、サーバー監視サービス「Mackerel」の時系列データベースを強化。DynamoDBは、RDSのようなインスタンスサイズによる課金モデルではなく、ストレージのデータ使用量とスループットを基にした課金モデルになっている。インスタンスサイズによる課金モデルでないデータストア系サービスとして、他にはS3、Kinesisなどがある。これらは、AWSの中でも、フルマネージドサービスと呼ばれる位置づけとなるサービスだ。フルマネージドサービスは、ElastiCacheのようなそうでないものと比較し、AWSに最適化されていて、サービスとしてよくできていると感じている。Mackerelの時系列データベースのスタックの一つとして、DynamoDBを採用している。時系列データベースの開発は、コストとの戦いだったために、それなりにコスト知見が蓄積してきた。以下は、2018年4月16日時点での情報を基にしている。冒頭に書いたように、「ストレージのデータ使用量」と「スループット」を基にするため、インスタンスサイズモデルと比較して、よりアプリケーションロジックがダイレクトに反映されるコスト構造になっている。正確なコスト定義は、公式ドキュメントを参照してほしいが、これを初見で理解するのはなかなか難しい。データ使用量のコストモデルはGB単価なため把握しやすい。スループットに関するキャパシティユニットの概念が難しい。以下では、各要素について、メンタルモデルを説明する。Calculatorに適当な値をいれてみながらコストを見てみるとだいたいの感覚をつかめると思う。ストレージのデータ使用量ストレージのGB単価は、$0.25/GB/月であり、S3のStandardストレージクラスと比較して、およそ10倍程度となる。聞くと割高に聞こえるが、画像やブログのテキストデータなどを格納しなければ*1、それほど高いというわけではない。実際、1TBのデータ使用に対して、$300/月程度のコストとなる。DynamoDBはSSD上に構築されている*2ようなので、安定して低レイテンシという性能特性があるため、大容量データをひたすら保持するというよりは、エンドユーザに同期的に応答するようなユースケースに向いている。スループットスループットによるコストには、「秒間のread数」と「秒間write数」と「対象のアイテムサイズ」が要素として含まれる。S3のように月のAPIコール数の合計により課金されるわけではなく、予めどの程度のスループットとなるかを予測し、事前にキャパシティとして確保しておく必要がある。したがって、見込んでいる最大のスループットにあわせてキャパシティ設定することになり、正味のリソース消費量よりも余分にコストがかかることに注意する。Scalingにより、余分なコストを抑えられる可能性がある。スループットによるコストは、大雑把には以下の特性をもつ。「秒間read数」または「秒間write数」に比例してコストが大きくなるアイテムサイズを1KBに固定したときの「秒間write数」の単価は「秒間read数」の約5~6倍程度となる。読み取り整合性を結果整合性のある読み込みにすると、「秒間read数」のコストは1/2となるreadまたはwriteしたアイテムのサイズに比例してコストが大きくなる「アイテムサイズ」のコスト単位はreadとwriteで異なる。readは4KB単位で比例し、writeは1KB単位で比例する。グローバルセカンダリインデックスおよびローカルセカンダリインデックスを利用する場合、writeする度に、内部的にインデックスの更新作業が走るため、writeコストが大きくなる。*32番目、4番目、5番目の特性がwriteスループットの大きいユースケースでDynamoDB利用が割高と言われる所以である。consitency)とwriteの差は、アイテムサイズが最小単位の場合では5~6倍程度となる。アイテムサイズがより大きい場合では、readとwriteの差はより大きくなる。複数アイテム操作DynamoDBは、同時に複数のアイテムを操作するAPI(BatchGetItem、BatchWriteItem)があり、これらを用いてアプリケーションの性能を改善することができる。基本的には、キャパシティユニットの消費を抑えられるわけではないため、これらのAPIを用いてコストが下がるわけではない。Queryについては、単一の読み取りオペレーションとして扱われる*4。これについては最近まで見落としていた。フィルタ式フィルタ式を用いると、クライアントとDynamoDB間のネットワーク通信料を削減できる。以下の表では、いくつかのケースで、スループットコストを試算している。実際には、readとwriteのワークロードは両方発生するため、readとwriteのコストの合計値となる。コストはap-northeast-1のもの。10800表をみるとわかるように、writeのコストが大きくなりやすい。ネットワーク同一リージョンの他のAWSサービスとの間で転送されたデータは無料となる。転送処理コストが発生する。https://aws.amazon.com/jp/vpc/pricing/によると、TokyoリージョンではGB単価が$0.062であり、AZ間通信の$0.010/GBの6倍あるため、あなどれないコストになる。知る限りのDynamoDBのコスト削減策を書いてみる。ここにある方法以外の策がほしい場合は、そもそもDynamoDBに向いてないユースケースか、アーキテクチャレベルで再設計する必要があるかもしれない。リザーブドキャパシティDynamoDBには、EC2のリザーブドインスタンスのように前払いにより、コストを下げるリザーブドキャパシティがある。https://aws.amazon.com/jp/dynamodb/pricing/によると、前払いした分のキャパシティ消費が$0になるわけではなく、別途時間料金が設定されており難しい。最大効率では、1年間前払いで、約50%程度の割引になり、3年間前払いでは、約75%程度の割引になるはず。Scalingにより、固定的なキャパシティ割り当てから、実際に消費したキャパシティユニットにより近づけることで、コスト削減できる。一日のキャパシティ削減回数には限りがあるため、インターバルの小さいキャパシティ増減には対応できない。DAXDynamoDBのシャーディング機構は、プライマリキーを内部ハッシュ関数への入力とし、内部的なノード配置を決定する。したがって、特定プライマリキーにreadまたはwriteが集中すると、テーブルのキャパシティを増やしても、1つのノードの性能限界にあたってしまう。readについては、前段にmemcachedのようなキャッシュを挟むことで対応できる。Acceleratorを使う。throughキャッシュとして動作し、DynamoDBのストレージまで到達してから、DAX上のアイテムに書き込み、レスポンスを返す。一方で、読み込みは、インメモリキャッシュのレスポンスを返すため、readが支配的なワークロードで効果を発揮する。DAXの動作モデルについては、https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/DAX.consistency.htmlが詳しい。DAXは自分で使ったことがないので、DAXそのもののコストについては理解が浅いが、インスタンスタイプベースのコストモデルになっている。TTLDynamoDBではアイテムの削除もwriteとして扱われる。時間経過による自動削除を許すケースであれば、TTLにより、writeコストを削減できる。TTLによる削除であれば、キャパシティユニットを消費しない。TTLはアイテムごとに設定できるため、RedisやMemcachedと同じような感覚で扱える。内部的にはコンパクションのタイミングで削除されるため、設定したTTLの時刻になった瞬間に削除されるわけではないことに注意する。前述したようにDynamoDBは、writeが支配的なワークロードで、コストが大きくなりやすい。メインDBとなるMySQLやPostgreSQLはwriteスケールアウトしづらいため、DynamoDBを使いたいケースにはwriteが支配的であることは多いように思う。スループットコストの特性からみて、基本的には、writeの回数を減らすか、アイテムサイズを小さくすることで対処する。writeの回数を減らすには、一つのアイテムに詰め込んで書き込むことになる。単純に詰め込んでも、アイテムサイズに比例して、一回あたりの書き込みコストが増加してしまう。そこで、例えば、1KBが最小単位なため、1KB未満のデータを書き込んでいる場合は、1KBぎりぎりのサイズになるように、データを詰め込んで書き込む。アイテムサイズを小さくするには、なんらかの手段で圧縮し、バイナリとして書き込むという手段がある。バイナリとして書き込む場合は、アイテムの追記が難しい。追記するには、一旦アイテムのデータを読み出してから、データを連結して書き込む必要があり、読み出しコストが余分にかかる。リスト型やマップ型の要素としてバイナリ型を使って意味があるケースであれば、素直に追記できる。バイト)」と書かれており、桁数ベースなので、バイナリとして扱うほうがサイズ効率はよい。https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/CapacityUnitCalculations.htmlあとは、属性名の長さがアイテムサイズに含まれるので、長い属性名を付けている場合は、短くするとよい。VPCエンドポイントにより回避できる。S3とDynamoDBのVPCエンドポイントは、ゲートウェイVPCエンドポイントと呼ばれるタイプのエンドポイントで、プライベートなDNSエンドポイントが払い出されるわけではなく、VPCのルーティングテーブルを変更し、L3でルーティングする。Gatewayのコストは問題なく削減できる。まとめDynamoDBのコスト構造と、自分が知るコスト削減手段を紹介した。DynamoDBは、データモデルとコストモデルのための公式ドキュメントがもちろん揃っているのだが、計算式はそれなりに複雑になので、妥当な感覚を掴むまでに時間がかかった。コスト見積もりし、サービスインしたのちに、実際の使用量を確認し、改善策を打つことで、徐々に理解が進んできた。CPU、メモリなどのハードウェアベースのキャパシティプランニングとは異なり、アプリケーションロジックフレンドリーな計算モデルなため、アプリケーション開発者がコスト見積もりやスケーリング対応をしやすいサービスになっている。Lambdaのコスト構造については、次のエントリ内で紹介している。https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Limits.html#limits-items*2:https://aws.amazon.com/jp/dynamodb/*3:プライマリキー単体と比較して、プライマリキー+ソートキーの複合キーの作成により、追加のwriteコストが発生することはないと認識しているが、ドキュメントを見つけられなかった。Migrationクラウドへの移行を含むデータセンター(以下DC)移行事例を基に、WebサービスをDC移行するための基本的な技術要素を紹介します。具体的には移行手順、データベースのデータ移行、ネットワーク、DNSなどです。最近、社内で大規模なDC移行を実施しつつあり、DC移行とはなにかをメンバーへ共有するための文章でもあります。#4の発表内容を書き下ろしたものです。Docker1000台同時SSHオペレーション環境を構築するにあたって、手元のローカル環境の性能限界の問題を解決するために、オペレーションサーバをSSHクライアントとすることによりSSH実行を高速化した。Registry)を用いて、ローカル環境とオペレーションサーバ環境を統一することにより、オペレーションサーバの構成管理の手間を削減した。この記事では、ホストインベントリとしてのMackerelと、並列SSH実行にすぐれたAnsibleを組み合わせ、オペレーション対象のホスト情報をプログラマブルに管理する手法を紹介した。工夫点として、並列SSH実行する上でのパフォーマンスチューニングやレガシーOSでの対応について紹介した。並列度をあげるとforkするプロセスの個数が増えてローカル環境のリソースをくいつぶすという問題があった。加えて、並列度が小さいと実行終了まで待たされるという問題があった。ローカル環境のOSやハードウェア性能が人によって異なるため、ローカル環境を統一して整備する手間があった。毎日利用する用途ではないため、利用頻度に対する整備コストが大きかった。そこで、ローカルから対象ホスト群に接続するのではなく、オペレーションサーバをクライアントとして対象ホスト群に接続する仕組みに変更した。これにより、スケールアップが容易になり、普段利用しているサーバ構成管理ツールを用いて、複数ユーザが同じ環境を利用できるようになった。オペレーションサーバを対象ホスト群と同じデータセンター内に配置すれば、SSHクライアントと対象ホスト群とのレイテンシが小さくなるため、実行速度が向上する可能性があるというメリットもある。playbookの開発にはオペレーションサーバではなくローカル環境を用いるため、ローカル環境とオペレーションサーバ環境の差異を小さくできるほうがよい。そこで、Dockerを用いて、ローカルとオペレーションサーバ共通の環境を構築する。システム構成システム構成を図1に示す。単一サーバから命令を各サーバへ送信するPull型のイベント送信モデルになる。対象ホストの流れに沿ってSSHログインする。オペレーションサーバ上では、並列SSHツール(Ansible)が起動し、記述したplaybookにしたがい、オペレーションを実行する。対象ホスト一覧は、ホストインベントリ(Mackerel)のAPIから取得し、フィルタ(Ansibleのfilter)により、除外パターンを記述できる。Ansibleそのものとplaybook、スクリプトなどが入ったDockerイメージをコンテナリポジトリ(ECR)にPUSHし、オペレーションサーバ上でPULLしておく。運用観点では、オペレーションサーバのホスト名、Dockerイメージ名、コンテナ名などを覚えてオペレーションはしたくない。参考のため公開している。これは社内事情を吸収するための層になるため、汎用的ではなく、そのまま動くわけではない。Dockerイメージのビルド、ECRへのプッシュ、オペレーションサーバへのデプロイ、オペレーションサーバが動作するかどうかチェックするテストのタスクを定義している。ローカルのDockerコンテナ上で引数指定したコマンドを実行する。オペレーションサーバにSSHしつつ、引数指定したコマンド実行する。オペレーションサーバ上のDockerコンテナにて、引数指定したコマンドを実行する。一斉にOSのパッケージを更新したいなど、コマンドをroot権限で実行したいことはケースはたくさんある。Ansibleでは、Becomeにより、対象ホストにてコマンドをsudo/suを用いて、インタラクティブパスワード入力でroot権限実行できる。sudoerの秘密鍵がローカルにあるため、オペレーションサーバ経由で対象ホストにsudoerとしてログインするにはひと工夫必要になる。forwardingを用いた。forwardingにより、オペレーションサーバ上のssh-agentプロセスがUNIXドメインソケットを提供し、オペレーションサーバ上のSSHクライアントがそのソケットから認証情報を読み出し、対象ホストへのSSH接続を認証する。forwardingは、セキュリティポリシー上、問題ないか確認した上で利用したほうがよいと考えている。上記のssh(1)のmanにも書かれているように、攻撃者がagentにロードされた認証情報を使って、オペレーションすることができてしまう。forwardingを用いることは好ましくない。forwardingを有効するために、-Aオプションを用いている。本格的なサーバ構成管理をするわけではないため、シェルスクリプトを実行できれば十分だ。Ansibleにはrawモジュールやscriptモジュールがあり、シェルスクリプトを実行できる。rawモジュールとscriptモジュールのメリットは、対象ホスト上のPython環境に左右されずにオペレーションできることだ。2.6をインストールして使うなどの手間が増える。5Ansibleの実行ログのGit保存どのサーバに対してオペレーションしたかを記録するため、ログをとっておくことは重要だ。furoshiki2を用いて、Ansibleのコマンド実行ログをGit保存している。内でansible-playbookの実行に対して、furo2コマンドでラップするだけで使える。まとめと今後の課題AnsibleとDockerを用いて、オペレーションサーバ経由で、大量のサーバに同時SSHオペレーションする環境の構築例を紹介した。forwardingによる権限エスカレーション、raw/scriptモジュールの利用、furoshiki2によるログのGit保存がある。並列SSHすることが目的であれば、Ansibleはややオーバーテクノロジーといえるかもしれない。具体的には、YAMLにより宣言的に記述されたplaybookや、各種Ansibleモジュールは今回の用途では不要であり、これらの存在は余計な学習コストを生む。そこで、シンプルな並列SSHコマンド実行ツールとして、最近発見したorgalorgに着目している。サーバとの接続に対してプロセスをforkするAnsibleと異なり、orgalorgはgoroutineを用いるため、より高速な動作を期待できる。forwardingに対応していない*4ことと、AnsibleのPatterns機能が、ホスト管理上非常に便利なため、今のところはAnsibleを利用している。09:40AnsibleとDockerによる1000台同時SSHオペレーション環境Tweetもっと読むコメントを書く2017-12-312017年のエンジニアリング振り返り日記はてなに入社して4年経った。2017年12月2日2017年のエンジニアリング活動を一言でまとめてみよう。時系列データベースの開発にはじまり、なぜかIPSJ-ONEで登壇し、その後IPSJ-ONEでの構想をベースにはてなシステム構想を考え始め、ウェブサイエンス研究会でストーリーとしてまとめ上げつつ新たな可能性に気づき、それを実践していく場としてウェブシステムアーキテクチャ(WSA)研究会を立ち上げた。一方で、仕事では、昨年の振り返りに書いているように、エンジニアとしての専門性を発揮する機会が薄れてきたという問題意識が、いよいよ深刻な課題へと変貌したように感じている。それも残念ながら自分一人だけの問題ではなくなってきた。この課題をエンジニアリングそのものではなく、人間のスケールアウトでは解決できない、組織アーキテクチャの課題であると捉えている。組織アーキテクチャの課題を解くための鍵は、今のところ「未来を定義する」「未来に向かって集中して取り組める環境をつくる」ことだろうと仮定している。前者の未来については前述のシステム構想があり、後者の方法論として今年実践する機会のあったプロジェクトマネジメントがある。したがって、来年は、今年構想したビジョンを技術と組織の両輪を回し、実現し始める、ということが目標になる。その裏には、エンジニア個人としては技術を作る技術をやっていきたいと思いつつ、生活時間の大半である業務の課題はマネジメントであるというギャップをどう埋めて一つのストーリーとしていくかが重要になるだろう。ここまで、いきなりまとめに入ったのだけれど、2017年に力を注いだ各トピックについて細かく振り返ってみる。アプローチとの出会いとビジョンの構想プロジェクトマネジメントアウトプット時系列データベースの設計・開発・運用このTSDBのオレオレ実装を、半年毎日コード書いて頑張っていたのだけど、リリース前に疲弊しまくって睡眠もうまくとれなくなってしまったので、途中までになってしまった。個人でやるプロジェクトとしては、ひと通り動くまでに時間がかかりすぎ、細かくロードマップを引きづらかったので、サーベイを続けて、新たな課題を発見し、その課題を小さく解決する手法を編み出したい。TSDBの開発は、大きな成果だと思っており、この知見を横展開するために、より汎用的なアーキテクチャにできないかと考えたのが、TimeFuzeアーキテクチャ構想だ。時系列データベースに限らず、大規模な計算機システムのモニタリングを支えるデータ処理アーキテクチャが好きなので、今後のライフワークとしていきたい。(まつもとりー)さんの昨年の振り返りをみてみよう。さんとは今年1年非常に仲良くさせていただいて、12月はなぜか毎週会って何かイベントごとをこなすようなぐらい、企業・アカデミア方面で関わることが多かったように思います。いつか、企業とアカデミアの両方の要素を含む新しい研究会みたいなものを一緒に作っていけるといいな、ぐらいに一方的に信頼しており、色々と今年は無茶をお願いしましたが、できるだけその無茶をちゃんと責任をもってサポートできるようにしたいと思います。今年は、まつもとりーさんのおかげもあって、学術研究コミュニティとの関わりが深くなった年だった。ペパボ・はてな技術大会では考えたビジョンをみてもらって、自分なりにウェブシステム全体をみてストーリー化し、それに対して議論していただいて、最後は「企業とアカデミアの両方の要素を含む新しい研究会」としてウェブシステムアーキテクチャ研究会を一緒に立ち上げることができた。その中で気づいたのは、学術研究のアプローチにより、ウェブシステムの分野におけるある種の限界を突破できるかもしれないということ。ここでの限界というのは、同じことの繰り返しで積み上げによる進化をしていないじゃないか感と、シリコンバレーの巨人の西洋技術を取り入れるだけで自分たちの存在価値とはなんなのだろう感を指している。それらに対するアプローチは既にあり、前者は体系化、後者は徹底したサーベイと自分なりの思考からの新規性ということになる。このあたりのよもやまについてはTwitterにあれこれ書いていた。ちなみに、学術研究のアプローチを企業でのエンジニアリングに導入することで何が起きるかについては、まつもとりーさんの下記の2つの記事にすべて書かれている。GeekOutコラムなにより重要なのは、そもそもなにがやりたいのかという自分の欲求と、それが実現したらどんな世界になるのかをイメージすることだとまつもとりーさんは何度もおっしゃっていた。前者はともかく後者はまあいいんじゃないと思いがちだし、実際何度もそう思った。現場の泥臭い運用をやっていれば、なおさらそう思う。前者だけであれば個人の趣味でしかないので、食べていくために仕事をしないといけないとなると費やせる時間は限られる。そこで、欲求が世界にどう作用するかを考えることで、やりたいことを仕事にできる...はず*3。いうことをずっと考えていた1年だった。してちょっとずつ自分なりの道をつくりつつあるのも、まつもとりーさんのおかげだなあとしみじみ思います。いつもありがとうございます。プロジェクトマネジメント時系列データベース開発とクラウド移行のプロジェクトを丸ごと任された結果、物事を前に進めるための条件というものがあることを体感で理解したように思う。これをウェブオペレーションチームの一部で実践しはじめ、小さな範囲でうまくできそうだということがわかってきたので、来年はチームというか部署全体で適用していきたい。これらについては、まだアウトプットしていないのでどこかでアウトプットしたい。daiksyさんの薦めで、RGST2018に応募していたのだけど、残念ながら選考で落ちてしまった。SREの分野のマネジメントって、SRE本以外に世の中に知見があまりなく、逆にチャンスだと思うが、自分が追求することではないと思っているので、誰かこれをはてなで追求したい人がいないかを探している。yuuki/portpinger-rs以前開発していたdrootが、[capze](https://github.com/yuuki/capze]とともにオンプレミス上の大きめのサービスで稼働しはじめ、明らかになったバグを修正したりしていた。して実装され、公開された。starsとかになっていてすごい。ブログ登壇内容をベースにそれをできるかぎりしっかり文章にまとめるということをやり続けている。いうと、アウトプットのスケーラビリティを非常に強く重視していて、登壇資料はあくまで当日その場のためのものであり、文章として後に残すことが自分のためにも重要だと考えているためだ。最小のインプットで最大のアウトプットが鉄則。いっても、数とかどこで登壇したかは問題ではなく、何を考え何を話したか、それぞれの登壇に何かしらの挑戦があったかが重要だと思う。2017-12-23あとがきエンジニアとしてやりたいことと、仕事で実際にやっていることとの乖離が大きくなってきた。そもそも、仕事ではだいたいその場しのぎの解決しかできず、あとは家に帰ってがんばるということがこれまでほとんどではなかったかとすら思う。世の中のすごいエンジニアもみんなそんなもので、もっとたくさんのプライベート時間を費やしているか、技術力が圧倒的だから少ない時間できれいに解決できるに違いない、自分はまだまだなのだという気持ちでいたのだけど、どうやら必ずしもそういうわけではなさそうだと感じはじめた。人が増えれば解決するはずだと、信じていたが脆くもその願望が打ち砕かれつつある。サーバ増やしてもスケールしないのと同じでアーキテクチャの問題。乖離を埋めるためには、どうしたらいいのか。技術力を発揮するというより、組織やプロジェクトをマネジメントすることが必要だと自分で導出してしまったため、矛盾しているような気もする。マネジメント、あれほどやりたくないと言っていたのだけど、それが課題となればやるしかない。自分の技術力向上については、WSA研を目安に研究志向でアイデアをOSSとして実現しつつ、より高みを目指したアウトプットとして論文を書いていきたい。道をつくるを載せておき、来年また思い出せるようにしておく。tomomiiさんに道の概念を話してもらってから、自分の道とはなにかということを頭のなかでずっと考えている気がする。*1:前者は僭越ながらはてなブログ大賞に選出させていただきました。*2:イメージすることについては、以前書いた記事で紹介させていただいた、イメージできることを実践するを連想する。EntriesSearchスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。