2020-01-05

The Amazon Builders' Library がなかなか面白い

タイトルが全て。みんな読んでみてほしい（主語がでかい）。
aws.amazon.com
Amazon が自社のシステムを構築する中で構築してきたノウハウを集めた場所。以前 Cloud Design Pattern みたいなものがあったけど、より背景事情を深めつつ洗練されている印象。昨年末に発表されてから素早く翻訳されており、日本語で読めるコンテンツとしてはかなりよいものだと感じた。
内容についてっは、分散システムがなぜ難しいのか、ということから始まり、タイムアウトやキャッシュ戦略、ヘルスチェックなど特定のトピックでの課題について深めていく形。ときどきに出てくる用語や現象について個別項目の知識はインターネットに散在しているが、メリットだけでなくどういうリスクとトレードオフなのか、どのレイヤで考えるのか、まで伝えてくれており、知見の結晶という感じ。コンテンツの追加が楽しみだ。
ちなみに分散システム自体の知識はあまり解説してくれず、AWS Developer Blog にちょっとリンクが貼ってあったりする程度。この辺の前提知識は、今だとOreillyの本かな。

分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計

作者:Brendan Burns
出版社/メーカー: オライリージャパン
発売日: 2019/04/20
メディア: 単行本（ソフトカバー）

2019-11-30

AWS Solution Architect Professional を取得した

ちょっと機会があったので、AWS Solution Architect Professional という認定を取得した。この試験自体は知っていたが、資格試験系全体にあまり興味がないのもあり、スルーしていた。実際に受けてみて、知識の確認・補完としては悪くないと思ったので書いておく。
AWS 認定ソリューションアーキテクト – プロフェッショナル

AWS Solution Architect Professional ってなに

公式の説明はこんな感じ。一般的な「アーキテクト」の能力（の一部）を評価する、という印象。

認定によって検証される能力

AWS で、動的なスケーラビリティ、高可用性、耐障害性、信頼性を備えたアプリケーションを設計し、デプロイする

提示された要件に基づくアプリケーションの設計とデプロイに適した AWS のサービスを選択する

AWS で複雑な多層アプリケーションを移行する

AWS でエンタープライズ規模のスケーラブルな運用を設計し、デプロイする

コストコントロール戦略を導入する

https://aws.amazon.com/jp/certification/certified-solutions-architect-professional/

サンプル問題があるので、まずはこれを見るのがイメージしやすい。典型的な課題やユースケースを出し、AWSを使って解決する最適な手段を選択肢の中から選ぶ感じ。前提が多いものもあり、1つの企業内でやってる自分なんかだと、普段はあまり縁のない状況も多くあった。
ちなみにAWSの認定ってざっくり言うけど、実はいろいろあるらしいというのも今回知ったところ。
AWS 認定 – AWS クラウドコンピューティング認定プログラム | AWS

実際に受けてみた感触

だいたい10月から準備し始めて、11月はじめに試験を受けた。試験を受ける、そのために勉強するという体験がそもそも大学院入試以来で、緊張やらペースづくりからどうやっていこうねという状態からスタートした。
自分の性格的に漫然と過ごしていてもまず勉強しないので、最初に試験に申し込んで締切を作ってからスタート。締め切りを作るのだいじ。その後の対策としてやったことは、おおよそこの3つ。

会社で勉強会をして強制的に時間をつくる。
模試と対策講義を見て傾向を知る。
AWS が出している Blackbelt Seminar の資料を眺めて足りない知識を補完する。

勉強については、AWS自体はずっと（初めてAWSについて発表してからでも8年だ）見てるし、その間にいろいろ変化も見てきた・会社でも使用を広げてきたので、多少知識を補完すればいけるかなという目論みがあり、実際に模試を受けてもそんなに悪くはなかったので、この作戦は悪くなかったと思う。
勉強して一番役に立つと感じたのは、実際にリリース情報やサービスの概要は見ていて「何をするものか」をなんとなく把握していても、「どんなユースケースでハマるか」の肌感がない領域の知識を得られること。頭の片隅に置いておいて損はないタイプの知識だと思う。自分で構築・運用しているものや、社外で近い領域の人からインプットをもらう機会があればいいが、そうでない領域についてもある程度網羅的に得られる機会があるのはよかった。自分の場合は長らく触れていなかった AWS Organization のフル機能だったり、手を動かすのをサボっていたSQS Kinesiis あたりの非同期処理の設計。ただし、やっぱり自分で触ってないと実感はこもらないので試験対策だけで勉強する部分ばかりになるとちょっとつらいし、ある程度の知識・経験は前提として持っている方が役立てるものだと思う。
他には、「AWSでやるならどうするか」という観点で考え続ける機会が得られる点はよかったかな。現実の課題を解決する上ではもう少し自由に手段を考えるのだけど、現代においてはまずクラウドプラットフォーム上で取りうる最善を考えた上で、それでもやりづらいところのみ作り込む・足りない要望を出す、という順は悪くないと思うので、こういう縛りプレイはよい方向に転がるはず。まあしかし、ソースコードを変更できないとか、理不尽な組織構造が前提になった問題にあたると、さすがにそこを変更しようよという気持ちになることもあるのだけど。
良くも悪くもコンソールを触ることすらなく勉強できる範囲なので、スキルの確認という意味ではあくまで参考にする程度かなというのは全体の感想。

勉強内容

自分の場合の事例。

社内の勉強会を週1で開催する。だいたい1-2時間くらい時間を確保。
まずはひとつ下の Solution Architect Associate (SAA) を受けてみることに。
- 黒い本徹底攻略 AWS認定ソリューションアーキテクト ? アソシエイト教科書を読んで勉強。どういう領域が出題されるか、体系的に書いてある感・安心感を得られるのが書籍のいいところ。
- 模試を受けて感触を得る、足りない部分を把握する。模試ではどこが間違ったか教えてくれないので、せめて迷ったサービスについてはメモっておくと後で勉強しやすい。
- AWS INNOVATE というオンラインカンファレンスでちょうどセッションやってたので見て雰囲気をつかむ。これはまさに学校の受験対策という風情でよかったので、AWS様にはぜひとも復活させてほしいコンテンツです。
SAA本試験
- テストセンターに行って受けた。オンラインで開催する試験を行う専用の会場で、手荷物を預けた状態で専用のPCが並んでいる部屋に案内され、そこで受験する。最近は漢検なんかもこういう場所で受けるらしい、知識が20年前で止まってて全く知らなかった。
- 小さくて解像度の荒いディスプレイを見続けてちょっとつらかった。
- 867/1000で合格。時間はわりと余ったが、見直しなどせずにサッと出てきてしまった（よくない）。
Solution Architect Professional (SAP) に向けて勉強。
- AWS INNOVATE に Professional 対策講座があったので見ておく。Associateと同様、まさに試験対策という趣でよかった。
- 模試を受けてみる。85%。Design for New Solutions という分野が弱いことがわかった、この辺は↑にも書いた通り手を動かすことをサボってた分野でもある。
- INNOVATE と模試で弱いなと思ったサービスの Blackbelt Seminar を読んでいく。日本語のスライドだと1つ10分くらいでサクサクいけるとテンポよく読んでいける。
- AWS公式のコースにある該当ホワイトペーパーに行けるのでそれも読んでみたが、2,3読んだところで飽きた。自分にはあまり合わない、楽しさが足りなかった。
SAP本試験
- 別会場、土日であることもあってかSAAの時より人が多かった。隣にいるのは気にならないが、正面の席を立つ人など視界内で動かれるとさすがにちょっと気になる。
- 今度はディスプレイが少し大きいものの、相変わらず解像度低くて荒いし、アスペクト比もなんか変な気がした...。
- Associate のノリでゆっくり問いてたら時間がなくなり、結局最後ギリギリになってしまった。180分集中するのはだいぶ疲れる。
- 結果は合格。837/1000
内容について
- 試験内容については、守秘義務があるので細かいことは言えない。
- 日本語で受けたものの、翻訳に違和感を感じたらすぐに英語で読むようにした。これはよかったと思う。
- 回答方針は「出題者の気持ちになって考える」がよいと感じた。多少前提条件が足りなくてもクラウドのプラクティスに乗るのが善という価値観に立ってみる。

まとめ

AWSの認定を受けてみた。知識の確認と補完にはそれなりによいとは感じる。AWSのイベントで認定者ラウンジとか見たので、次は使ってみよう。
f:id:wtatsuru:20191201012134p:plain:w200

2019-10-22

ISUCON9 予選に出て敗退した

だいぶたってしまったけど、ISUCON9 の思い出を供養しておく。
サザン不定形ストーリーズというチームで出て、結果は予選敗退だった。
isucon.net

チーム編成と事前準備

出るぞとだけ言ってギリギリまで何もしてなかったのだけど、直前に誘ってもらったチームがあったので入れてもらった。
事前に集まって、多少準備をしてた。これまでチームメンバは出たことあるメンバで組むことが多かったので、コミュニケーションチャンネルなど1から整理していったのが新鮮だった。

Alibaba Cloud アカウントを作ってみんなで触る練習
GitHub リポジトリ、Slack チャンネル、Scrapboxページなど準備
言語、当日の集合
予習ネタ集める

当日の動き

当日、明らかに一番コード書けないのが自分だったので、足回りの整備と作戦とりまとめみたいな動きを主にしていた。

10:00 ルール読み
- 他のメンバは、最速でアプリケーション動かしてコードを読む担当、Alibaba Cloud でインスタンス起動して全員サインインできるようにする、などやってもらってた
10:30 nginx ログ設定だけ入れて初期ベンチ回す
- alp でログ解析するところまで。alp 予選前日にリリースされてるし、Starも増えててISUCON専用ツールとして存在感を増している感がある。
- 他のメンバは、コード読みとデプロイ整備をやってもらった。デプロイスクリプトは前日にひな形置いてたやつベース。
11:00 作戦会議
- 各自の作業概要共有、大まかな方針確認。
- ここでキャンペーン試行錯誤すべきか、なども会話できた。順調だった。
初手の改善
- 自分は、デプロイからスムーズに動くまでをやってた。手元からログ解析打てるようにする、デプロイ直しつつ nginx で static file 配信、ついでにルーティングファイルからエンドポイントごとに nginx location 分離。画像アップロード先修正忘れてたので対応したり。
- 他の2人で N+1 ペアプロ、カテゴリを初期化時にオンメモリで持つように。
- キャンペーンの値もちょっといじってみて様子を観察。
13:32 作戦会議2
- やることはやった段階での作戦会議。
- キャンペーンやると購入リクエストが殺到する、/buy が遅くて売上られていない、外部APIがたまにタイムアウトしてる、ということはわかってたので、対応を検討。
  - API リトライって話も出てたけどなんでやらなかったんだっけ...
複数台化、リクエスト試行錯誤
- 自分は粛々と作業して複数台化。MySQL 外部からアクセスしてアクセス先IP固定、初期化やアップロード関連など一部の処理だけ01に振る、など粛々と作業。
- アプリケーション的には、トランザクションが長い対策として for update 消せるやつは消したりしてた。
- innodb_lock_timeout = 3 で意外と簡単にタイムアウトしてくれた。実際に使ってみたのは初めてだった。
14:30 作戦会議3
- 複数台化の残作業。カテゴリをオンメモリ化した関係で全台に initialize 渡す必要がある > ここは自分が担当
- 購入リクエストのトランザクションがとにかく長いので、「購入中」というステータスを作って分離することを考える。がっつりペアプロしてもらった。自分はこっちは戦力外。
16:00 作戦会議4
- /buy 分割したことでボトルネックが移った。買えないときに素早く失敗してる。
- item 関連、user 関連タイムラインが遅いのでインデックス貼っていく。/login は遅いけど bcrypt だしレギュレーション的にどうしようもないねって会話した。
17:00
- 複数台でリクエスト受けた瞬間に fail 多発
- 並列でAPI投げてる？など疑って httpclient 使いまわしてみたり
- キャンペーンガチャやってみても同様に fail が多発する
18:00
- 最後に fail しなかったそれっぽいスコアで終了。たしか2700くらい
- 3710 がベストスコアだった。

振り返り

準備はまあまあよかった
- 起動してデプロイしてログを観察する、まで含めて
問題は適度に複雑でよかった
- 外部APIとトランザクション。普段あまり扱わないネタだけに、いい経験になった。
最初は状況認識はできていた
- 上と合わせて、良くも悪くもISUCONに慣れてるということ
途中から焦りがでた
- APIのリトライ、あとでやろうとして忘れ去っていた案があった。
落ち着いてシステムの理解ができていなかった
- ホワイトボードに描いてコードも眺めてたつもりだったが、結果としては状態遷移の考慮が甘かったのが敗因となっている。
- ユーザ視点、システムが実現しようとしていること、を落ち着いて考えることが必要だった。自分はそこができた立場だっただけにちょっと悔しい。
Go 言語にみんな慣れてなかった
- 仕事で使い込んではいないメンバ。APIエラーをダンプするだけでもそれなりに時間を食ったり何かとアクションが遅かった。
- 自分はコード書くの遅かった
  - ミドルウェアあたりはサクサクいく、サーバサイドのコードに手を入れようとしたときに何かと遅れる。
  - 最近自分で手を動かすことが減っており、趣味においても技術系やそれ以外のこと含めインプットに比重が置かれている。多少は手を動かせる状態でありたい。

まとめ

こういうアドレナリンが出るイベント、たまにはいいなと思った。現場感覚持っておきたい。そろそろ決勝に行くのもきつくなってきた最近だけど、もう一回くらい行きたいな。

2019-05-02

基盤開発観点からみたはてなのAWS活用のこれまでとこれから

こんにちは、id:wtatsuru です。この記事は、はてなエンジニア Advent Calendar 2018 8日目の記事です。昨日は id:taketo957 による aws-cdkを用いた開発事例の紹介 - taketo957の日記でした。
このエントリでは、はてなでAWSをどのように使ってきたかを、サービス基盤の開発・運用の観点から振り返ります。

黎明期

はてなで最初にAWSをプロダクションに投入したのは2011年、はてなブログβリリース時でした。当時は EC2 のみのオンプレミス側と同じ構成からスタートしています。

VPNを張って共通のネットワークに置き、監視やセットアップでもオンプレミス側となるべく共通のものを使う、という思想で構築・運用を開始しています。今で言う EC2 Classic のみ、アカウントもrootのみという古典的な時代ですが、ELB, VPC, RDS など徐々にリリースされていくクラウドサービスを検証・導入していきました。オンプレミス側ではSSDがバリバリ活躍し始めた頃ということもあり、I/O 性能が出ずに苦しむことも多かった頃です。

共通基盤構築と利用の拡大

その後、AWS利用のノウハウが溜まって基盤整備が進み、新規構築でクラウドを使うことも多くなってきました。はてなとしては、Mackerel のリリースなどサービスの幅が広がっていく時期でもありました。

多くのサービスへ利用を拡大していく中で、はてな全体で共通の基盤を使っているゆえの課題が出てきました。
例えば、IAMの権限をAWSサービス単位で広く取っている物が多いために、別のサービスリソースを触ってしまう危険性があり、コンソールを触る際の安全性が低い、などが挙げられます。1つのものを触るときに影響する範囲が大きく、基盤レイヤに何かを導入するときには既存の共通基盤や多様なサービス全体を見る必要があるため、基盤開発メンバ以外がさわりにくい状況が生まれており、改善の速度自体にも課題を感じていました。
費用管理上も、どのサービスがどれくらい使っているのかわかりにくい、という課題がありました。この点はタグベースの費用分類である程度解消しています。サーバ構築時に流れる chef recipe から動的にタグ付けするなどの運用により、サービス単位の利用料金を把握できる状態としています。
コスト配分タグの使用 - AWS 請求情報とコスト管理

アカウント分離

クラウド利用が進み、そのメリットを活かしたサービス開発が行われる時代が来ました。はてなでも、Mackerel の AWSマネージドサービスを使った時系列DBの構築や、はてなブログの独自ドメイン証明書基盤などが開発され、今後ますます広がっていくと予想されます。プロダクト単位で必要なサービスをいかにうまく使えるかがサービス開発の鍵になります。

そんな中、基盤部分をある程度独立させてサービスレベルのスケーラビリティを高めて開発速度を上げることを目的として、AWSアカウント単位での分離を進めています。AWS Organizations や VPC Peering などアカウントを増やしやすい状況も後押ししています。
基盤開発観点では、開発者が触りやすいように社内構成のドキュメントの整備とガイドラインの策定を行いつつ、アカウントを増やしやすい仕組みや、社内の標準形を探る検証を行っています。今年のインターン成果もその一例です。

以前から続いているサービスも多いためまだ分離は一部のサービスのみですが、新規構築分では分離しながら、既存アカウントのマイグレーションも徐々に進めていく予定です。今年の re:Invent でもマルチアカウントを助けるサービスが次々発表されています。AWS Transit Gatewayでネットワーク構成は大きく変わりそうですし、AWS Resource Access Manager もかなりマイグレーションに役に立ちそうな予感がしています。目まぐるしくベストプラクティスが変わる状況ですが、うまくサービス開発をスケールさせることができる形を探っていきたいと考えています。

おわりに

はてなでAWSをどのように使ってきたかを、サービス基盤の開発・運用の観点から振り返りました。サービスの成長やAWSの変化によってそのときどきでのベストプラクティスは変化していきますが、うまく活用していきたいと考えています。
サービス開発を加速する基盤を作りたいエンジニアも大募集中です。
SRE (Site Reliability Engineer) 職 - 株式会社はてな

明日は id:papix です。

2016-11-06

『思考する機械　コンピュータ』を読んだ

文庫思考する機械コンピュータ (草思社文庫)

作者: ダニエルヒリス,W.Daniel Hillis,倉骨彰
出版社/メーカー: 草思社
発売日: 2014/06/03
メディア: 文庫
この商品を含むブログ (8件) を見る

コンピュータの原理的なところから、プログラミング、並列コンピュータなんかに関してまで、平易な言葉でわかりやすく、かつ本質をついた説明がなされていた。個別の論点に終始してしまいそうな内容が短く綺麗にまとめられていて感動した。例えば暗号に関して、情報量と絡めて「潜在的には一定の規則を持ちながら、表面的には不規則な数字列をある方法で用いる」とある。概念や考え方はなんとなくわかっていたものの、ここまですとんと腑に落ちる説明には初めて出会った。
一番印象に残ったのは、序章のこの部分である。

コンピュータの面白いところは、コンピュータが本質的にテクノロジーを超越しているということであり、私はその本質について語るためにこの本を書いている。

最初読んだタイミングでははっとさせられ、読み進めるに従ってじわじわ納得し感動を覚えた。この目的があるからこそ、全体像をわかりやすく描き出せているんだろう。
情報系の素養がある人間ならさらりと読めるし、そうでなくてもじっくり考えれば読めるようになっている。一通り見直すにはちょうどよかった。高校生の時にこの本に出会っていたら、進む道は少し違っただろうか、と考えさせられる本の1冊だった。

2015-11-02

ISUCON5 本戦出場してきました

ISUCON5 本戦に、同僚の id:motemen id:ichirin2501 と一緒に 2nd Party Cookies として出場してきました。
結果は7位に終わり、トップの fujiwara 組に3倍近い差をつけられてしまう結果となってしまいました。

まず全体

今回の題材は、社長が作ったマイクロサービスアプリの改善。予選の凝ったDB設計とアプリからはがらっと変わって、DBは PostgreSQL に変わったもののそこは焦点からは外れ、外部APIコールの最適化がメインのテーマとなりました。
予選に続いてとてもいい問題で、ベンチマークもスムーズで非常に楽しめました。運営の皆様は大変だったと思いますが、ありがとうございました。
個人的には、初動や全体の方針はそこまで悪くなかったものの、インフラ担当としての開発支援や視野の広さ、実現に持っていく力という部分での差の大きさを痛感しました。

当日の動き

Slack ログを見ながら、自分の動きを中心に振り返ってみます。自分以外のやつはちょっと間違いあるかもしれません。

開始から初動

11:00 開始
全員のログイン設定、デプロイまわりを整える
計測系のパッケージ入れたり最低限のセットアップ
nginx のログ調整で alp でのアクセスログ解析準備
Perl 実装への切り替え、一発目のベンチマーク。1102
11:30 くらいから最初のログを見つつ、DBの様子・サーバの環境を観察したりして作戦を考える

最初の作戦会議

1時間くらい観察したところで作戦会議。

`/data` で外部APIを叩きに行くところが支配的。リソースぜんぜん使い切れてない。ここをキャッシュするとよさそう
DB が PostgreSQL で驚いたが、データ量も小さく触らなくてもよさそう。 endpoints テーブルをハードコードする以上のことはあまり必要なさそう？
APIも手元から叩けないし PostgreSQL そのままだと通らない（結局プラグインが必要とのことでした）で、手元環境作るのけっこうしんどいと判断。3台あるので実験用には別のものを使う

まずはやれるところを

やり残したこと、まずやるとよさそうなことの準備を進める。

外部APIの接続先とリクエスト時間をログに残して観察。キャッシュで50倍くらいまではいけそう、などと検討
nginx で keepalive, static file 配信（実はミスってた）
1台なのでまずは Gazelle + Unix domain socket 化
memcached を1台用意してキャッシュする
zipcode も郵便番号と住所なんだしAPI叩かなくていい？じゃあDBに入れるか、という大きめの改善を by id:motemen さんがサッと入れてくれた。かっこいい
そろそろCPUを使い切ってるので、3台使ってみる。PostgreSQL 外部から接続でちょっと手間取ったが、これ以降は PostgreSQL 全く触っていない。

キャッシュを入れた時点で14519で暫定1位、zipcode で18768、全台使って 33774。このへんで14時過ぎ、勢いづいてくる。
いったん作戦会議を挟む。

ゆきづまり

特別賞が10万点ってことは、そのへんまではいけるはず、もっと飛躍が必要ということでいろいろ考える。

static file のアクセスが目立つので gzip 入れて etag / expires などで改善という話を id:ichirin2501 とする。そして効かなかったので戻す。config のちょっとしたミスで効いてなかったことがあとで判明。。
JSON parser 負荷高い、という仮説のもと id:ichirin2501 が改善を始める
nginx のCPU使用率が目立つ。クライアントの keep-alive はわりときいてる。worker 2, Starlet にして proxy-app 間を keep-alive をきかせてみる。
API リクエストの並列化は優先度高いのでは、という相談をしてそちらは id:motemen さんに依頼。
サーバ構成で DB と nginx は分けてみた

何だかスコアが伸びないし fail しまくる、nginx 499 出まくっている、という現象に悩まされる。並列リクエストの方は、再現性の微妙なエラーで行き詰まる（endpoints の1つが1コネクションしか受け付けない、ということだったのでそれもあったかもしれない）。さらに zipcode のデータを全部メモリに読み込んでいた結果、swap 発生で全台死にかける、など散々な状況。デバッグしにくいものを実機上でデバッグしていたりして、互いにロックしてしまったのがもったいなかった。

復活

いったん元に戻し、あらためて一つ一つ見ていく。

static file の配信まわりでミスっていたのを id:ichirin2501 の指摘により修正。マジ感謝
proxy-app 間の keepalive をやめることで 499 大幅減少。間のいろいろな改善が効いて 52097。3位くらいだったと思う
nginx ミスがわかったので再びクライアント最適化系を入れる。sys 減らそうとネットワーク系も少しいじる。

記録残すの忘れてるが、16:30過ぎくらいに 76000 くらいまでいってた気がする。トップまであと5万よっしゃいくぞ、と盛り上がった。この時点でもまだサーバリソースは使い切れていなかった。

失速、敗北

70000こえたあたりで、fail が目立ち始めた。API の内容をキャッシュしすぎている、というようなエラー。
よく出る Tenki API のキャッシュを切ってみるものの、スコアが1桁落ちる。
一度再起動試験を入れて無事に成功。しかしスコアは全く伸びず。。
id:motemen id:ichirin2501 2人がかりのキャッシュ対策を見守りながら、最後の1時間でマージするちょっとした改善の準備をさっと行う
API の傾向とレスポンスを観察。tenki の Last-Modified が3秒おきなのを把握。If-Modified-Since つけてもダメ、と思ってしまったが、何かミスがあったような気がしてならない。。
特定のAPIのみのキャッシュ期間の調整がうまくいかない。バグがあったのかもしれない
しょうがないので static file 関連の最適化を外し、わざと遅くすることで fail を防ぐ。5-6万あたりで安定して通るようになった

最終スコアは 57,492。fail してもおかしくない状態だったし、悔いの残るスコアになってしまった。

反省点

具体的な反省点。

外部APIの特性をギリギリまで見ていなかった。そこが焦点になった時点でAPIの特性を観察しておくべきだった。
開発効率へもう少し気を配りたかった。開発環境がない、デプロイが微妙に遅いなどの点。トップの fujiwara 組は、サーバ上に Squid を立てるなどして手元で開発できるようにした、とのこと。そのあたりにコストをかけておきたかった。
もう少し全体を見て、方針のリードをしたかった。とくに本戦では配置と最適化のポイントの絞りこみが重要なことはわかっていたので、引いた目線へのリソース配分はすべきだった。

これから

2年前のISUCON3 よりは手ごたえがありましたが、もうひと伸びの必要性を感じました。上位は全て出題経験者だったし、ひとまず社内ISUCONなんかで出題経験を積みたいなーとなんとなく思っています。
あとは普段の仕事を真面目にがんばるだけですね。。要素技術についてはそんなに負けてないと思うので、幅を広げる・考察を深めるというあたりに注意してがんばっていきたいと思います。

wtatsuruの技術方面のブログ

はてなスタッフ id:wtatsuru です。日常ブログはこちら https://tatsuru.hatenablog.com/

The Amazon Builders' Library がなかなか面白い