re:annkara

日々学んだことを書き留めておく。

ISUCON11予選にて敗退しました。

ISUCONの季節ということで、職場の同僚の@lunarxlark@Aki_Mineoの3人でチーム:コバミネとして参加してきました。

アプリケーション周りを主に@Aki_Mineoが、インフラ周りを@lunarxlarkに見てもらい、自分はレギュレーションやマニュアルを読み込んだり、アプリケーションの導線を確認してどの辺が点数として伸ばせそうか確認するようなことをしてました。

参考値ベースとなりますが、29614 点 の151位でした。一時、上位25位以内に入ったときはみんなで喜んだものでしたが、その後は得点を伸ばせずという感じで、今年もまた悔しい思いをしました。

当日何をやったかなどは、@lunarxlarkのブログが詳しいのでこちらを見てみてください。

ISUCON11予選に参加して惨敗した | /home/lunarxlark/.config/blog

以下、個人的な振り返りを箇条書きで。

  • 予選当日マニュアルを読み込んでポイントの稼ぎ方は把握
  • ただし、グラフに関する加点ポイントが最後までよく理解できなかった
  • マニュアルを読んだにも関わらず、アプリケーションマニュアルの存在を見落とす(チーム全員)
  • 点数の取得に影響したか正直分からないが、事前にドキュメント類を必ず読み込むぞ!と意気込んでいたので一番のショックだった
  • インフラ周りの整備、主にデプロイ周りなどを@lunarxlarkがやってもらえたので、実装に集中できて体験がすごくよかった
  • スロークエリログやアクセスログ解析、netdataなどのツールを使ってざっくりとボトルネックぽい箇所を把握してはいたが、実際にどうやって変更すればよいかといった点で右往左往してしまってポイントを積み上げられなかった
  • ボトルネックの把握の解像度をあげること、どうやって解決するか(実装・インフラ)の実装力を上げることが重要だと痛感させられた
  • 普段アプリケーションの実装をゴリゴリとしてるわけではないので、練習を積むことで実装力を高めたい
  • 他のチームのリポジトリなどを見ると、時系列で振り返りやすいログを取ってたのでその点も真似したい

今年で3回参加したことになるが、今年が一番悔しい思いをしている気がする。 来年はもっと練習を積んで本選に参加できるようにしたいと思います。

最後に、ISUCONを開催してくださった皆様に本当に感謝いたします。めちゃくちゃ楽しい時間でした!! 本当にありがとうございました!!

2020年を振り返る

2020年を振り返りたい。

雑多

コロナで色んなことが変化したと思う。
いち早く収束することを祈るとともに、自身もできる限りのことをし続けていく必要がある。

仕事

あることがあって自分自身で手を動かしていくことを意識的にやめた。

自分がエンジニアの仕事を始めたときには、自身のスキルを向上させることばかりを目的に動いていた。しかし、それは個人としては良いかもしれないが結果として周りと共有できないのであれば組織としてうまくいくことはないのだと気づいた。

技術的なことを追求することを辞めたのではなく、組織として継続して結果を出し続けるためにはどうすればよいのか、考え行動した一年だった。

エンジニアとして技術的なスキルは伸びなかったとは思うが、チームをどう成長させていくかみたいな点で一歩引いて見れるようになって、行動できるようになったと思う。

趣味

自作PCを作った。

もともとVにハマって、Vtuberがやっていたゲームを自分でもやってみたく、給付金もあったのでパーツを集めて自作してみた。

最初パーツをくみ上げて電源をつけても何も音沙汰がなかったので焦ったけど、もう一度組み合わせるとちゃんと動いたのでよかった。

今ではAPEXと開発用のデスクトップとして稼働している。

もう少し金銭的な余裕ができれば、上位パーツを利用しての自作を行いたいと思っている。

まとめ

ここには意図的には書いてないけど、大きな動きのあった一年だった。

この大きな変化をもとに来年はより良い一年を過ごせるようにしていきたい。

「イラストでわかるDockerとKubernetes」を読んだ

Twitterで知って、先日たまたま書店で見つけたので買ってみた。

イラストでわかるDockerとKubernetes (Software Design plus)

イラストでわかるDockerとKubernetes (Software Design plus)

  • 作者:徳永 航平
  • 発売日: 2020/12/05
  • メディア: 単行本(ソフトカバー)

どんな本か??

130ページ程の書籍なので、DockerやKubernetesを普段利用している人であれば1-2時間ほどで読み切れる分量で、題名にある通りイラストや図表が多いので非常に分かりやすい。

DockerやKubernetesの基本的な説明をしつつも、普段あまり意識しない「コンテナランタイム」について焦点を当てていて、コンテナの内部構造やコンテナのライフサイクル(生成から削除まで)について仕組みの面から説明してくれている。

どんな人向けか??

中の仕組みをあまり理解しなくともDockerやKubernetesを利用することはできるが、裏でどんな風にコンテナが作成・削除されているのか仕組みが気になる人には入門書として非常に適していると感じた。

DockerやKubernetesといったコンテナプラットフォームを技術的な側面から深めていきたい方がとっかかりとして読んでみる、また「コンテナランタイム」(CRI/OCIなど)とは何ぞやということを理解したい人にも向いているかもしれない。

最近、KubernetesがDockerを非推奨にするような記事を見かけたけど、それを理解するためにも良いなと思った。

@inductorさんの記事や@jacopenさんの記事を理解するための前提知識、ないしは補完するものとして読んでおいて損はないと思う。

KubernetesのDockershim廃止における開発者の対応 - inductor's blog

Dockerは非推奨じゃないし今すぐ騒ぐのをやめろ - Cloud Penguins

雑感

DockerやKubernetesの中身を知らなくても正しく動いているときには問題ないかもしれないが、何かが起きたときに中の仕組みを知っていると解決できることが多々あると感じている。

すべてを理解して利用することは難しいかもしれないけど、ブラックボックスとして扱わないで、自身の知見というものを深めていきたいと思う。

ISUCON10 振り返り

少し時間が経ってしまいましたが、ISUCON10にチームBanBanジーとして参加しました。
最終スコアは参考スコアとなりますが、1048ポイントでフィニッシュでした。

SSHで時間を溶かす

今回、踏み台サーバ経由で与えられたサーバ環境に接続する必要がありました。
当日配布されたマニュアルを参考にssh.configを編集してたのですが、SSH力が低すぎて1時間ほど溶かしてしまいました。

ssh.configやローカルポートフォワーディングなど、実務ではほとんど触ったことがなかったので、ちゃんと理解しておきたいと思いました。

初手

最初の方でやったことです。

  • ドキュメント読み合わせ
  • 導線確認
  • サーバ・システム構成の確認
  • 初期ベンチマークの取得
ドキュメント読み合わせ

去年の反省も含めて当日ドキュメントをちゃんと読み込みしようと思ったのですが、前述のSSH周りの件で詰まってしまったのでちゃんと読めなかったです。

本当であれば、Bot周りの話やベンチマークの挙動、スコア計算周りはちゃんと理解しておくべきだったと思います。

導線確認

導線確認ではどんなアプリケーションなのかざっと把握するためにブラウザから実際にアクセスしていました。

今回は出題者の方がRecruitということもあって、SUUMOをモチーフにしたアプリケーションでした。なんとなく、ここらへんで更新系の処理が少なそうで参照系が多そうだなぁという印象を持っていました。

サーバ・システム構成の確認

稼働しているプロセスの確認とサーバリソースの確認をしました。

nginx - アプリケーション - MySQL が稼働しており、CPUは1コア・メモリが2GBほどでなかなかにシビアなサーバリソースでした。

初期ベンチマークの取得の取得

ある程度どんな環境なのか把握できた段階で初期ベンチマークの取得を行いました。

ベンチマーク実行中にはTopコマンドでリソース使用率の傾向を見ていましたが、CPU使用率が90%以上であり、かつMySQLのプロセスが支配的であったのでこれはDB周りがボトルネックになっているんだろうなぁというのがこの時点での感想でした。

今となってはですが、初期ベンチマークを取得する前にアクセスログ周りの設定やツールの整備、スロークエリログの解析準備を行ってから初期ベンチマークを取得すればよかったと思います。

やったこと

ざっくりと。

  • ツールの導入(alp/go_one)
  • nginx のアクセスログをLTSVに変更
  • スロークエリログの解析
  • index の追加
  • サーバ構成の変更
  • 実装の変更
  • nginxにキャッシュの設定を追加
index の追加

スロークエリログを見ながらインデックスを張ったりしてました。
とりあえずスコアは微増しましたが、適当すぎたのでちゃんとSQLを学ぼうと思いました。

ALTER TABLE isuumo.chair ADD INDEX idx_popularity(popularity);
ALTER TABLE isuumo.estate ADD INDEX idx_latitude(latitude);
ALTER TABLE isuumo.estate ADD INDEX idx_longitude(longitude);
ALTER TABLE isuumo.estate ADD INDEX idx_popularity(popularity);
ALTER TABLE isuumo.estate ADD INDEX idx_rent(rent);

サーバ構成の変更

MySQLサーバのCPU使用率が高いことがわかっていたのでDBサーバを分離しました。

最終的には nginx - アプリケーション - MySQL を1台ずつで構成する形になりましたが、nginx/アプリケーションのCPU使用率的にはほとんどボトルネックはなかったので1台のサーバでよかったと思います。
DBサーバを分離する案は出ていたのですが、実際にやったことがないということもあって手を出せずにいました。

後々、他の参加者のブログを見てたりすると、分割することでスコアが上がったという記事を見かけてたりするので、チャレンジしても良かったなと後悔しています。

余談ですがMySQLを分割するときにユーザごとに接続可能IPアドレスというものがあることを知らなくて、別サーバに分割するときにだいぶ苦労しました。

実装の変更

アクセスログからAPIの実装で直せる場所がないか探していました。

/api/estate/low_priced と /api/chair/low_pricedのAPIがnazotte検索や検索系APIに次いで、トータルの呼び出し回数・処理時間が多そうだったので実装を見てました。

実装としては都度同じクエリを実行して同じ結果を返却するように見えたので、オンメモリ上にキャッシュするように実装を変更しました。
トータルの処理時間としては1/60くらいにすることができましたが、スコア的には微増だったような気がします。

nginxにキャッシュの設定を追加

/api/estate/search と /api/chair/search APIの呼び出し回数と処理時間が一番多かったため、このAPIをどうにかしようとしてました。

実装をちゃんと変更できればよかったんですが、実力不足のためなんとか他の手段でできないかと検討してました。

コードをざっと見た感じ、クエリパラメータからクエリ実行用のパラメータを取得してSQLを発行しているように見えたので、安易に同じクエリパラメータであればその結果をnginx側から返却すればMySQLの負荷が減るんじゃないかと考えました。

最終的には上手くいったように見えたんですけど、ベンチマークの結果が安定しなかったり、/api/chair/search も同様のキャッシュの設定を入れると必ずFAILしたりと綱渡り感が半端ない感じになってしまいました。

ちゃんと実装を理解していればたぶん取らない手法だと思うんですが、結果としてこの修正をすることで1000オーバすることができました。

振り返って

去年よりもだいぶできることが増えたなと感じるとともに、まだまだできることがあるというのも実感できました。

今までなんとなく知識としてなんとなく知っていたものを、実際のサービスに活かせるようにするという点で実力も経験も足らないのだと改めて実感することができました。

このような機会を与えてくださったISUCONの運営の皆様に感謝いたします。また来年参加したいと思います。本当にありがとうございました。

日本語文書内の不自然なアルファベットを検出する

Kibana 7.2.0から日本語に対応している。
使っているとちょいちょい不自然なアルファベットが紛れ込んでいることに気づいて、2度ほどissueを挙げた経緯がある。

目視で検出するのも良いが、機械的に検出できないかと思ってGoで実装した。

GitHub - annkara/Unnatural-Alphabet: 日本語文書内の不自然なアルファベットを検出する。

単純に正規表現で 日本語1文字 + アルファベット1文字 + 日本語1文字 のパターンにマッチするものを出力するだけ。

試しにv7.4.0のja-JP.jsonファイルを対象に使ってみるとissueとして挙げた二か所が検出できたので、ある程度の精度は保てていそう。

というか、他にもあることに気づいたので最新のバージョンで直ってなかったらissueあげておこう。

"kbn.management.objects.objectsTable.howToDeleteSavedObjectsDescription": "ここから保存された検索などの保存されたオブジェクトを削除できます。保存されたオブジェクトの生データを編集することもできます。通常、オブジェクトは関連アプリケーションでのみ編集され、こn画面で編集するよりもそちらのほうが賢明です。",

"timelion.topNavMenu.save.saveAsDashboardPanelDescription": "Kibana ダッシュボードにチャートの追加が必要ですか?できます!このオプションは、現在選択されている式を、他のオブジェクトの追加と同じように Kibana ダッシュボードに追加可能なパネルとして保存します。他のパネルへのリファレンスが使用されている場合、リファレンスの表現を直接保存する表現にコピーして、リファレンスを削除する必要があります。他の表現式を保存するよう選択すrには、チャートをクリックします。",

"xpack.monitoring.metrics.beats.failRates.droppedInPipelineDescription": "N 回の試行後ドロップされたtイベントです (N = max_retries 設定)",
"xpack.monitoring.metrics.beatsInstance.failRates.droppedInPipelineDescription": "N 回の試行後ドロップされたtイベントです (N = max_retries 設定)",
"xpack.security.loginPage.welcomeDescription": "Elastic Stack へのi入口",

参考

不自然なアルファベットを見つけるtextlintルール | Web Scratch

CiNii 論文 -  日本語文章校正ツール"Chanterelle" : 入力ミス及び表記揺らぎについて

2019年を振り返る

 

reannkara.hatenablog.com

 

2019年を振り返る。

 

2019年の目標に関して

2019年の年初にあげた目標を達成することはできなかったが、Elastic StackやRedisなどのミドルに関しては、実運用に足る知識と実践を積むことはできたと思う。

 

Goに本格入門した

縁あってGoper道場の第六期生として参加させて頂いた。

 独学で学んでいたGoだったけど、改めて体系的に学ぶ場を提供していただいて本当に良い経験となった。

人生初のライトニングトークもさせていただいて、アウトプットする大切さを改めて痛感した。

docs.google.com

 

仕事について

 テックリードみたいな役割をやっていた。

役職にあるわけじゃないのだけど、そういう役割を持った人が存在することで上手く回るんじゃないかと思って意識的にやっていた。

技術的な意思決定を行うこと、チーム員が課題に直面した際の助言を行うこと、コードレビューを行うこと、課題に対してあらかじめ技術的な調査を行うことなど、様々な面で気を配ることが多かった。

その反面、色々と得られるものも多かったと思う。この辺の経験をうまくアウトプットしたいなと思っている。

 

総じて

2019年、当初思っていたようなことはできなかったけど、それでも様々な面で色んな経験とインプットをすることができていて非常に実りある一年だったと思う。

来年以降はもっとアウトプットすることを意識していきたい。

優れたアウトプットは人を動かす

12月8日(日)に開催されたJuly Tech Festa 2019に参加してきました。

2019.techfesta.jp

最近の自分の傾向として技術的な領域への関心と共に、チームビルディングやアウトプット、エンジニアとしてのマインドなど非技術的な側面にも興味が出てきました。なので、今回はそのような領域のセッションを中心に参加してきました。

参加してきたのは以下の4つのセッションです。

  1. Design Proposal は文化を創る
  2. 「極める、伝える、教える」の調和
  3. 「エンジニア像」を言語化し文化の礎を築く
  4. エンジニアはアウトプットによって成長できるのか?

ただ、今回はGMOペパボ社のP山さんによる基調講演中のhsbt文書が非常に良いなと思ったのでそのことについて書きたいと思います。

「ペパボっぽい」 エンジニアカルチャーを創る 言葉と仕組み - Speaker Deck

hsbt文書とは

基調講演の資料の中では以下のスライドに記載されている文章です。

https://speakerdeck.com/pyama86/pepabotupoi-enziniakarutiyawochuang-ru-yan-xie-toshi-zu-mi?slide=84

別のイベントでP山さんが登壇されたセッションの記事を見ると、@hsbtさんが記述したことからhsbt文書と呼ばれてるそうです。

エンジニアが「優れたアウトプット」をするために必要なこと - ログミーTech

何が自分に刺さったのか

この文書を読んだときにどんな点が自分に刺さったのか考えてみると大きく2つの要因があると思います。

  1. 評価基準を明確にしている点
  2. 優れたアウトプットを定義している点
評価基準を明確にしている点

GMOペパボ社が重要視している価値観として「みんなと仲良くすること」というものがある。

この理念に沿った社員の評価を行う際には、他者と協力して何かを成し遂げたということに留まらず、その結果がまた別の良いコミュニケーションを生み出すことでその結果を優れたものとして評価できると明文化している。

つまり、被評価者が通常であれば取りうるコミュニケーションのスコープを大幅に超えて新たなコミュニケーションの連鎖を生み出し、アウトプットを生み出すことができればそれは優れた業績として評価ができると自分は解釈した。

良いなと思ったのがこういった評価基準を明文化し、共有できること自体が非常に価値あるものだと思ったので刺さったのだと思う。

優れたアウトプットを定義している点

hsbt文書の中では

優れたアウトプットというのは「アウトプットによって人に行動を引き起こさせたかどうか」

というように、明文化している。

自分がアウトプットに対して明確な考えを持っていないことにモヤモヤとしたものを感じており、この文章により新しい視点を得たことによってアウトプットに対する認識が明確になったと思う。

振り返って

hsbt文書は優れたアウトプットの大枠を明文化していると思うのだけど、個別具体的な部分までは記述されていない。
これはアウトプットというものが非常にスコープの広い概念であるので仕方のないことだと思う。

ただ、優れたアウトプットというものは人を動かすものであるという認識を常に持ちながら、自身が何かアウトプットする際には、これは人を動かし得るものなのか自問自答しながら行うことでより良いものが生み出されるのではないかと思う。

最初はJTF2019の感想をただ書こうと思ったのだけど、優れたアウトプットに突き動かされた一人として自身のアウトプットとして残してみました。

この文書がまた他の誰かの目に留まってまた別のアクションが生み出されると、この文書を書いた自分としても嬉しい限りです。

最後にJTF2019に関わった全ての人に感謝します。とても楽しい時間でした。ありがとうございます。