ジム通いをやめてリングフィットに切りかえた
先日、任天堂スイッチのリングフィットアドベンチャーの一週目をクリアした。
買ったのは昨年の6月くらいだったかと思う。
ジム通いを5年くらい継続していたこともあって、当初はジムとリングフィットを並行してやっていた。 しかし徐々にジムに行く頻度が少なくなってきたので、とうとう先月解約してリングフィット一本に切り替えることにした。
運動の目的
今のところ一番の目的は、デスクワークを集中して行えるようにして高い QOL をキープするためってところ。
2日くらい身体を動かさないとだるくなって何も捗らなくなってしまうのでそれの解消のために運動をする、って感じ。 すぐだるくなってしまうのは、運動神経が悪く普段の動きで自然に筋肉を使えないからなんでしょうね。 特に腹筋の力の入れ方をすぐに忘れて姿勢が乱れるので困っていた。
ジム通いについて
週3くらいで通っていて、フルでやった場合のメニューはこんな感じだった。
- クロストレーナー 20分
- マシンを使った筋トレ（上半身・下半身を日によって変えていた）30分
- 腹筋 10分
- ストレッチ 10分
- ランニング 20分
移動時間や着替えの時間を含めると、フルでやった場合には 2時間かそれ以上かかってしまっていたことになる。
また他にも困っていたことがあって、それは膝や足裏の筋の怪我が多発すること（シンスプリントや足底腱膜炎など）。 身体の使い方が下手くそなのが問題なのだけど、色々工夫してみてもすぐ感覚を忘れてしまうのでなかなか改善されなかった。 ストレッチを念入りにしたりしてみたけれど、筋肉痛ですぐ硬くなるのであまり効果がなかった。
リングフィットはどんな感じでやっていたのか
デスクワーク後の腰痛と肩こりに効くやつがうれしいなあということで、次のフィットスキルを重点的にやっていた。
- バンザイスクワット
- マウンテンクライマー
- プランク
- リングアロー
- トライセプス
ジム通いの代替なので、運動負荷は 30、リングコンの強度はマックスにした。 また、プレイ時間はリングフィット時間（狭義に運動している時間のみを計測できる機能がある）で 30分ほど。
リングフィットとは別に腕立てと腹筋もやることもあったのだけど、これらを合計しても1時間くらいに収まるようになった。
切りかえて良かったところ
ジム通いと比較してリングフィットが良かったことはたくさんあった。
- やり始める障壁が小さい
- 平日の残業をバリバリした日でも手軽にできるし、雨だからという理由でサボることがなくなったので、結果的に運動の頻度は上がった（週5くらい）
- 頻度が上がったことによって、以前習得した身体の使い方を覚えていることが多くなって捗った
- 重症な筋肉痛にならない
- インナーマッスルが鍛えられる
- リングフィットの腹筋ガードで腹筋の使い方を覚えられた
- マシンで鍛えるよりも、全般的に日常生活に役に立つ筋肉を鍛えられている感じがする
- 怪我をしない
- 基本的に関節に優しい
切りかえて良くなかったところ
一方で、良くなかったところもあった。
- ジム通いと比較するとアドレナリンが出ないので、終わった後の爽快感が足りない
- 心拍数は上がっても120くらいだし、呼吸が乱れてゼーゼーすることもない
- とりあえず、アドレナリンに関してはサウナで代替することに
- 消費カロリーが少ない（実働 30 分で 100 cal 強くらい）
- ちょっと太って痩せなきゃってなった時にリングフィットは無力
- 音楽を聞く機会が減る
- 代わりに聞くことになったのはリング君の励ましボイス
おわりに
平日はリングフィットをベースにするのはいいんだけど、休日にもっとカロリーを消費したいなあと思った時にどうしようかってなるのが課題。
ランニングは寒い季節にはやりたくないし、やりすぎると膝を壊すし。 Fit Boxing の方がカロリーを消費できるらしいので、前向きに検討している。
そういえば書いている途中で気づいたんだけど、音楽を聞く機会が減る問題は AirPods の外部取り込み機能を使ったら解決した。 つまり、AirPods で音楽を聴きながらリングフィットのサウンドもお気持ち程度に耳に入れておけばいいんじゃないかっていう。
リング君の励ましボイスも悪くはないけれど、テンションアップ効果で言うと 高速 BPM の HR/HM や アニソンには負けるかな（個人の感想です）。
未経験3人でISUCON11に予選参加しました
チーム「SLA一億パーセント」として @Kumassy @Gaku-Kunimi とISUCON11に参加してきたので、準備としてやったことや本番に経験したことについて書いていく。
ISUCONは簡単にいうとWebアプリのチューニングコンテストであり、面白そうと思いながらも必要とされる知識が多く敷居が高いと思っている人も多いと思う。
自分も未経験だし他の人を誘って参加するのはハードルが高いなあと思って二の足を踏んでいる人たちに向けて、どうやって練習すれば競技の土俵に上がれるのか、スムーズにチームビルディングができるのか、というところの経験を共有して、少しでもISUCONの普及に貢献できたらと思う。
TL;DR
- 初回練習の導入にチュートリアルを用意してモブプロするのは有効だった
- 三台構成にしてデプロイまでを短時間でできるようにするために、インフラ担当が素振りをちゃんとするのが大事
- 特にデプロイスクリプトのスムーズな作成と使用法の啓蒙が大事
- 結果は予選敗退だったが「測定して改善する」サイクルをチームで回せたという点で手応えはあった
前提
- 三人全員ほぼISUOCN未経験
- Webアプリの仕組みはわかっているものの、N+1問題やインデックスについては単語しか知らない、レベル
- 基本的なスタンス
- スコアガチ勢ではなくエンジョイすることを重視
- 全員社会人で他にやることもあるので、過去問8時間x3回の通し練の参加以外の練習は強制しない
- 立てた目標: "エンジョイ" できる程度のレベル上げをする
- ISUCONのセオリー「測定して改善する」を実践できるようになる
- 具体的には、alp (Nginxログ集計), pt-query-digest (SQLログ集計), netdata (モニタリング) など有名どころのツールを使えるように
- チームでやるべきことの分担をして効率的に競技時間を使えるようになる
- ISUCONのセオリー「測定して改善する」を実践できるようになる
- 分担は自分がインフラで他の二人はアプリを担当、実装言語はPythonを使用
事前の通し練習
- 環境構築はAWSのEC2テンプレートを使用
- t3.microで4台立てても一ヶ月数千円しかかからない、土日だけONにするともっと安い、何より環境構築が簡単
- 初回の練習は、インフラ担当の自分がチュートリアルを準備してきて、アプリ担当の二人のメンバーにベンチを走らせて測定・分析するところまでをモブプログラミング形式で体験してもらった
- 二回目・三回目は、各人が開始後の2時間（理想）に行うべき典型的なプロセスと、その後の高速化サイクルに慣れてもらうことを目指した
- 使用したAWSのインスタンスは練習後も電源をONにしたままにしておいて、やりたい人は延長戦ができるようにしていた
- 講評や参加ブログを読みながら再実装してスコア上げ
練習を通して思ったこと
- デプロイスクリプトは超大事
deploy_from_local.sh- git pull、ログの退避、サービスの再起動をワンコマンドで行うやつ
run_after_bench.sh- ログをリモートから持ってきて集計・分析するやつ
- ブランチを指定してデプロイできる機能はとても有用だった
- ISUCONをエンジョイできるようになるためには、少なくともインフラ担当が素振りを繰り返すことは必要
本番の動き（インフラ担当目線）
- 9:30
- 三人とも起床していてえらい
- 10:00
- 10:30-12:00
- 12:00-13:00
- 13:00-14:00
- 14:00-16:00
- 一番時間を食っていると思われる
/api/isuのN+1を修正しようとするも苦戦 - windows関数を使わないとできなくない？って思って調べながら試行錯誤
- バグを取って実装し切るもスコア上がらず
- 一番時間を食っていると思われる
- 16:00-17:00
- 他のメンバーのbulk insertや
/api/trendのN+1改善を実装してもらうも、逆にスコアが下がる - その時に
/asset/*へのアクセスが異常に増えたのが観測できたので、Nginxでの静的配信を実装- GUIのレスポンス向上は体感できるもののにスコアは伸びず
- ついでにNginxがディスクにbufferしてるerrorが出たので
client_body_buffer_sizeを調整したり - その他インデックス貼ってもらうも効果なし
- 他のメンバーのbulk insertや
- 17:00-18:45 （途中中断1時間あり）
- app二台構成にしようと思うものの、session振り分けが必要なことに気づいて色々調べるも結局実装できず
- アプリメンバの
/api/conditionの実装が終了するもマージまでは至らず - 再起動試験対策に、再起動してサービスが動いていることを確認
最終的には無事再起動試験には通り、9670点（330位) でfinishでした
振り返りと感想
- インフラ担当なのに二台構成に早めに手をつけなかったのは反省
- 戦えるレベルのスコアが出たわけではないけれど、ISUCONの型は身についたと思う
- 毎回練習を繰り返すごとに成長を感じられるのでよかった
- とはいえ圧倒的にスピードが足りてないので反復練習が必要
- 密にチームメンバで連携して開発ということをあまりしてこなかったので楽しかった
- ISUCONももう10回目なので、alpですぐ判明するボトルネックの改善やN+1解決でスコアが簡単に上がるような問題は出ないよなあっていう
- スコア計算式から求めていることを把握しなければいけなかったのかも？しっかり復習したい
- ここまで出題に開発コストがかかるイベントが続いているのは奇跡に近いと思うので、ISUCONの運営・スポンサーのみなさんには感謝の気持ちしかない
R3 ネスペに合格しました（実務未経験）
先日ネスペの合格発表がありギリギリながらも合格ということで。 受かる確率は半分切ってるなあといった手応えだったので、とてもうれしいです。
勉強してて思ったんですが、この資格は非常に「良い資格」だなあと。 「良い」の定義は色々あるとは思うのですが「合格を目指して勉強した時に、それ以外余計なことを考えなくても実力が身につく」とでも言いましょうか。 資格取得のためだけの試験勉強にならないし、逆にどうやって勉強すればいいのか路頭に迷うこともないという、まさに資格のあるべき姿を体現しているなあと感じました。 問題もそれなりに手間暇かけて作られている「味わい深い」ものが多く、解いていて楽しかったです。
基礎固め
もともとソフトウェアの人なので、レイヤー3以上の単語は聞いたことがあるが理解があやふや、レイヤー2以下や具体的な冗長構成の組み方に関してはほぼ知らない、といった状態で勉強開始しました。
そんな状態で役に立ったのが、次の二冊。
- インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門
- 仕組みと原理を逐一理解しながら読み進んでいけるので、「なんかよくわからんけど暗記しておこう」みたいなことがあまりない
- ネットワークは雑多なプロトコルをひたすら暗記するもの、という誤解をしている人に読んでほしい
- 5日くらいかけて何周か読んでじっくり暗記
- 徹底攻略 ネットワークスペシャリスト教科書
- 上の本だけでは試験範囲をカバーできないので教科書が必要
- PDF版があるのがすばらしい、困ったらすぐにCtrl+F
- まとめノート（覚える部分を赤字で書くような）を作りながら一通り読了
午前対策
はい
午後対策
- 過去8年分を二周
- 一周目は解説込みで理解できればいいや、の感覚で回すこと優先
- この意識を持ってしても午後IIを解き切るのはしんどいと思う
- 二周目については、どうやってこの答えを導いたのか、の思考回路も全て書き下した
- わからない問題についても考えうる選択肢とその理由を列挙
- 解説を読んだ後には、Evernoteなどを使って "正当/正しい思考回路/正答に辿り着けなかった原因" を赤で書き加えていくと良い
- 知らなかった知識はまとめにその都度追記
- 直前には「ネスペの基礎力」と「R1付属の一問一答」で抜けを確認
よかったこと
- ネットワークを生きた知識として理解できた
- 個々のプロトコルの仕組みは学びやすいが、それが実世界でどうやって使われるかについては実際の業務に携わらないと経験しにくい
- ネスペの問題を解くと必然的にネットワーク図を読み込まないといけないので、典型的なネットワークデザインをイメージできるようになる
- (ただし、自分で設計できるようになるにはもっと訓練が必要）
- ソフトウェアエンジニアリングをする上で、ネットワークがブラックボックスではなくなったので、自信を持ってトラブルシューティングができるようになった
本番
- 午後I
- 問1を解いて、OSPFと電話をどっちにしようかと迷って前者を選択して絶望、バーチャルリンクとか知らんがな
- 素点だとほぼ6割乗らないなという体感だったので、なかなか高い下駄があると思う
- 午後II
- BGPは基本知識以外ゼロなので回避、標準的だが重めの問題が多くて時間が足りなかったような印象（あまり記憶なし）
- 解答はメモってるので、復習を兼ねて自己採点/解き直しをするのも勉強になりそう
- 本番で出くわした問題は強く印象に残るものなのでね
- せっかくなので解き直したら別件で記事書こうかな
- 合格率は12.8%と、ここ10年で過去最低だったらしい
最後に
- 暗記する知識の範囲が広いので毎年チャレンジするとなるとそれなりに大変
- 一発合格できてよかった
- いい資格とはいっても、ガチャ要素はそれなりにある
- しっかり教科書の勉強した人でも、毎回受けて毎回確実に合格するような資格ではない（少なくとも実務未経験の場合）
- 六割で合格とはいっても無茶振りの設問（捨て問）が一定数あるので、合格点を超えるのはそんなに易しくない
- 講評で「正答率が低かった」とコメントされてるのは大体それ
- 一発合格を目指すのは精神衛生に悪いからやめたほうがいい
- なんだかんだいって200時間くらい勉強したと思う
- あくまで目安で、勉強時間を長くしても落ちる時は落ちるし、逆に短くても受かるときは受かると思う
- 過去問も8年解いたのは結構多い方なんじゃないかな
- 受かってもネットワークのスペシャリストにはなれません
- あくまでスタート地点に立ったというだけ
FP3級に合格（自己採点）しました
自己採点で学科（52/60）実技（45/60）で合格でした。
受験した動機
- お金まわりの基礎知識をつけるため
- 特に、知らないことで損しない/騙されないための知識
FP3級とは
- 6つの単元から構成
- 試験科目は学科と実技の二種類
- 二択 or 三択の問題形式、それぞれ6割正答で合格
- 実技は問題の種類が少ないので毎年内容が酷似している
使用教材
FP3級 過去問道場
- スマホで過去問を解きまくれる、充実した解説がすぐにチェックできるのがすばらしい
- 単元ごとに脳死で問題を回した
- 初見の問題はすぐ解説を読む、それも適当に読む、飽きたら読むのをやめて次にいく、何よりテンポが重要
- ３、４回同じ問題に遭遇すると、この問題/単語よく見かけるなあ、となるので、その時に解説を熟読
- そのうち一瞬で問題が解けるようになる
- ログを見たところ解いた問題数は延べ4000問くらいだった
みんなが欲しかった！FPの教科書
- 必要な知識がよくまとまっている
- テキストを読んでから問題を解くのが王道だけど未知の単語が多すぎて読むのが苦痛だったので、問題を適当に解いた後の知識整理に使用
- 巷では評判は良いけれど、なんでそういう制度設計になっているのか、という背景/思想の説明があまりないのが個人的には不満だった
- 悪い言い方をすると、単なる知識の羅列と語呂合わせの本になっている
- とはいっても、思想/背景を知ったところで試験で点が取れるわけではないというのも事実だが......
- これは試験の作り方に問題があるような気がする
勉強時間
- 測っていないのでわからないが、50〜100時間くらい（？）
感想
- FP3級の試験範囲（6つの単元）の設定自体はとても良い
- お金の教養を良いバランスで身につけることができる
- 一番有用だったのはタックスプランニング
- 自信を持って確定申告ができるようになる
- 逆に不動産の項目は業者向けの知識が多くてあまり面白くなかった
- 試験問題の作り方がイマイチ
- FPの勉強とライフプランニングの実践の隔たりは大きい
- FPは色々な制度や仕組みがあることは学べるのは確かだが、それらをどう使うかについては学べない
- 具体的な状況（若いうちに病気にになったら、事故に巻き込まれたら、家を買うことになったら）を想定して、どうすべきか検討するのはまた別の話
- 結局何事もトレードオフがあるし、「損しない知識 = 個々の制度の費用対効果」だけど、そういうのは個々に地道に調べるしかない
- 当然生きる上で直接的に役に立つハックが学べるわけではない
- 差額ベッド問題、不動産の損しない選び方、失業時に各種届出を申請する順番、などなど
- （みなさん色々教えてください）
- こういうのを知りたいのであればYouTubeなりで個別に漁った方が早い
- 差額ベッド問題、不動産の損しない選び方、失業時に各種届出を申請する順番、などなど
- とはいえお金に関しての教養や基礎力、特に調べたいときにキーワードで調べられるスキルが身に付くのは確か
- 受かるだけだったらとても簡単な資格なので、何から始めて良いのかわからない人にはオススメ
日商簿記3級を取得しました
受験した動機
- 修論を提出してヒマになったので、何か新しいことをやりたかった
- コロナの影響でCBT試験（ネット試験）が可能になって、手軽にいつでも受けられると知った
- 入社前研修の一環で、触りの部分だけをやって興味を持った
- 社会に出る前に、資本主義やお金についてベースとなる知識を持っていないと情弱になりそうだと思った（後付け）
自分について
具体的にやったこと
なぜ通信講座を申し込んだのか？
- 全く未知の分野なので、考え方がおかしいと困ると思った
- 本をチラ見したところ似たような単元が羅列してあったので、途中で飽きそうだった
- 取得するインセンティブがないこともあり、課金した方が強制力が働きそうだった （←これが一番大きい）
学習内容
- 8日間、およそ65時間（だいたい50〜100時間かかるらしい）
- 前半の4日半
- 1回30分全57回の講座を1.5〜2倍速で視聴
- その都度テキストの問題を復習、適当に飛ばしながら演習問題を解く
- 後半の3日半
- パブロフ簿記の中級と上級を二周くらい
- 付属の過去問6回分
教材の感想
- クレアール
- パブロフ簿記
- 網羅性がある神アプリ、みんなダウンロードするべき
- 勘定科目と金額を手書きする手間が省けるので、高速に学習を回せるのがよい
CBT試験本番
- パブロフ簿記のサイトの模擬問題の形式とほとんど同じ
- 紙二枚とボールペンしか使えなかったのでつらかった
- 書いた文字が消せないので、色々と慎重になってしまった
- 第二問の点数が低いのは、それで時間が足りなくなったため
振り返って
- ゲーム感覚でできたので楽しかった
- 簡単な資格とは言われているけれど、勉強不足だったり雰囲気で解いただけでは取れない資格だと思った
- 貸借対照表、損益計算書の意味するところが、実感を持ってわかるようになった
- 勉強時間をさらに短縮して50時間にするためはどうすればよかったか？
- 演習問題を解かないで、パブロフ簿記を早い段階から反復練習すればよさそう
- 6年も過去問演習しなくてもよかった
- CBT試験では例年第三問で出題されている試算表は出なさそうなので、適当に流すのもありだったのかも
- 資本主義やお金の知識が身についたか？
- 今のところあんまり実感がない
- 財務諸表については、作れるのもいいけど、読み解ける方が大事では？
- ビジネス会計試験3級、FP3級あたりの方が役に立ちそう
- これらもCBT試験が始まってほしい
- その時に簿記の重要性が改めてわかるようになるかもしれない
分散ファイルシステムGfarmのインストールメモ
前提
- Ubuntu 18.04
- server1とserver2は同じネットワーク上にあるとする
- server1でメタデータサーバ、ファイルシステムノード、クライアントノードを動作
- server2でファイルシステムノード、クライアントノードを動作
インストール
基本的なモジュールはaptで入れることが可能である。
今回はバックエンドにPostgreSQLを使用する。
sudo apt-get install gfmd gfsd gfarm-client gfarm-doc gfarm2fs sudo apt-get install postgresql python-psycopg2 libpq-dev
構築
メタデータサーバの構築
まずはメタデータサーバをインストールするserver1に、管理者として使いたいユーザでログインする。 ここでは、このユーザ名をmyuserとする。 また、認証方式としては共有鍵認証を使用する。
まずは -t オプションをつけてconfig-gfarmを実行し、設定内容を確認。
myuser@server1 $ sudo config-gfarm -A myuser -t
Error: No default cluster found
prefix [--prefix]:
metadata backend [-b]: postgresql
(available backend: postgresql ldap)
metadata directory [-l]: /var/gfarm-pgsql
metadata log directory [-L]: /var/gfarm-pgsql/pg_xlog
postgresql admin user [-U]: postgres
postgresql admin password [-W]: (auto generated)
postgresql user [-u]: gfarm
postgresql password [-w]: (auto generated)
postgresql prefix [-P]: /usr
postgresql version [-V]:
postgresql XML supported [-X]: no
postgresql data checksum support
[-E]: yes
metadata replication [-r]: no
digest [-d]:
metaserver hostname [-h]: server1
matadata admin user [-A]: myuser
matadata admin dn [-D]:
portmaster port [-p]: 10602
gfmd port [-m]: 601
auth type [-a]: sharedsecret
rc script for gfmd : /etc/systemd/system/gfmd.service
rc script for backend : /etc/systemd/system/gfarm-pgsql.service
gfmd conf file : /etc/gfmd.conf
gfarm client conf file : /etc/gfarm2.conf
gfmd pid file : /var/run/gfmd.pid
backend pid file : /var/run/postmaster.pid
WARNING: command not found: pg_ctl
WARNING: command not found: psql
pg_ctlとpsqlがないと怒られる。
二つのコマンドは /usr/lib/postgresql/10/bin/ にあるので、-P でPostgreSQLのprefixとして指定してみる。
myuser@server1 $ sudo config-gfarm -A myuser -t -P /usr/lib/postgresql/10/bin/pg_ctl
prefix [--prefix]:
metadata backend [-b]: postgresql
(available backend: postgresql ldap)
metadata directory [-l]: /var/gfarm-pgsql
metadata log directory [-L]: /var/gfarm-pgsql/pg_xlog
postgresql admin user [-U]: postgres
postgresql admin password [-W]: (auto generated)
postgresql user [-u]: gfarm
postgresql password [-w]: (auto generated)
postgresql prefix [-P]: /usr/lib/postgresql/10/bin/pg_ctl
postgresql version [-V]: unknown
postgresql XML supported [-X]: no
postgresql data checksum support
[-E]: yes
metadata replication [-r]: no
digest [-d]:
metaserver hostname [-h]: server1
matadata admin user [-A]: myuser
matadata admin dn [-D]:
portmaster port [-p]: 10602
gfmd port [-m]: 601
auth type [-a]: sharedsecret
rc script for gfmd : /etc/systemd/system/gfmd.service
rc script for backend : /etc/systemd/system/gfarm-pgsql.service
gfmd conf file : /etc/gfmd.conf
gfarm client conf file : /etc/gfarm2.conf
gfmd pid file : /var/run/gfmd.pid
backend pid file : /var/run/postmaster.pid
WARNING: PostgreSQL version 7.4 or later required: unknown
WARNING: command not found: pg_config
WARNING: command not found: pg_ctl
WARNING: command not found: psql
今度は、pg_config, pg_ctl, psqlがないと怒られてしまう。
これらの実行コマンドは、/usr/bin/ に存在するものの、 /usr/lib/postgresql/10/bin/ には存在しない。
これの解決には悩まされたのだが、-V 10 としてPostgreSQLのバージョンを指定してやると、両方のパスを探索してくれるようだ。
実際に実行するコマンドは -t を取って以下のようになる。
myuser@server1 $ sudo config-gfarm -A myuser -V 10
これでメタデータサーバがserver1で起動する。確認は以下のコマンドで行える。
myuser@server1 $ sudo systemctl status gfmd.service
_gfarmfsユーザが存在することを確認した後、共通鍵を生成する。
gfkeyの -p オプションで共通鍵の期限を設定できるが、ここではその期限を1年間とする。
myuser@server1 $ cat /etc/passwd | grep _gfarmfs _gfarmfs:x:129:134::/var/lib/gfarmfs:/usr/sbin/nologin
myuser@server1 $ vim /etc/passwd << _gfarmfs:x:129:134::/var/lib/gfarmfs:/usr/sbin/nologin >> _gfarmfs:x:129:134::/var/lib/gfarmfs:/bin/bash myuser@server1 $ sudo su _gfarmfs _gfarmfs@server1 $ cd /var/lib/gfarmfs _gfarmfs@server1 $ gfkey -f -p 31536000
.gfarm_shared_keyが新しくできていることを確認する。
_gfarmfs@server1 $ ls -la | grep .gfarm_shared_key -rw------- 1 _gfarmfs _gfarmfs 74 Aug 24 22:30 .gfarm_shared_key
ファイルシステムノードの構築
まずは、共通鍵をserver1, server2のmyuserのホームにコピーする。
myuser@server1 $ sudo cp /var/lib/gfarmfs/.gfarm_shared_key /home/myuser/ myuser@server1 $ scp /var/lib/gfarmfs/.gfarm_shared_key server2:/home/myuser/
ファイルシステムノードの設定と開始は次のようにしてできる。
myuser@server1 $ sudo config-gfsd -h server1 /var/gfarm created /var/gfarm created /etc/systemd/system/gfsd.service created /etc/unconfig-gfsd.sh config-gfsd success Please ask admin_user to register your host by the following command: /usr/bin/gfhost -c -a x86_64-ubuntu18.04-linux -p 600 -n 272 server1 After that, start gfsd by the following command as a root: systemctl start gfsd.service
myuser@server2 $ sudo config-gfsd -h server2 /var/gfarm created /var/gfarm created /etc/systemd/system/gfsd.service created /etc/unconfig-gfsd.sh config-gfsd success Please ask admin_user to register your host by the following command: /usr/bin/gfhost -c -a x86_64-ubuntu18.04-linux -p 600 -n 272 server1 After that, start gfsd by the following command as a root: systemctl start gfsd.service
次は言われた通りに、メタデータサーバのserver1で次のコマンドを実行して、メタデータサーバにファイルシステムノードを登録。
myuser@server1 $ /usr/bin/gfhost -c -a x86_64-ubuntu18.04-linux -p 600 -n 272 server1 myuser@server1 $ /usr/bin/gfhost -c -a x86_64-ubuntu18.04-linux -p 600 -n 272 server2
それぞれのサーバで、ファイルシステムノードを開始。
myuser@server1 $ sudo systemctl start gfsd.service myuser@server2 $ sudo systemctl start gfsd.service
実際にファイルシステムノードが動いているかどうかはgfhostで確認できる。
myuser@server1 $ gfhost -lv 0.00/0.01/0.00 s x86_64-ubuntu18.04-linux 272 server1 600 0(SERVER1_IP_ADDR) 0.00/0.01/0.00 s x86_64-ubuntu18.04-linux 272 server2 600 0(SERVER2_IP_ADDR)
クライアントノードの構築
メタノードサーバで生成された /etc/gfarm2.conf ファイルを /etc にコピーするだけで終わり。 （scpでやると権限で引っかかりやや面倒なので、直接コピペするのが楽かもしれない。NFSを使っても良い。）
動作確認
server1, server2で、gfarm2fsでGfarmファイルシステムをマウントすることで、通常のローカルのファイルと同じように操作できる。
myuser@server1 $ mkdir gfarm-mnt myuser@server1 $ gfarm2fs gfarm-mnt myuser@server2 $ mkdir gfarm-mnt myuser@server2 $ gfarm2fs gfarm-mnt myuser@server1 $ echo "Hello" > gfarm-mnt/hello myuser@server2 $ cat gfarm-mnt/hello Hello # アンマウント myuser@server1 $ fusermount -u gfarm-mnt myuser@server1 $ fusermount -u gfarm-mnt
参考資料
SC19に参加しました
これは、eeic（東京大学工学部電気電子・電子情報工学科）Advent Calendar 2019の10日目の記事です。
こんにちは、τ研M1のtkygtr6です。 SC19という国際会議に先日参加してきたので、その紹介と感想を書こうと思います。
SCとは
SC (Supercomputing Conference) とは、文字通りスーパーコンピューティングの一流国際会議です。 高性能計算 (HPC) に関わるシステム、計算手法、ネットワーク、ストレージなどをスコープにしています。 スパコンの耐障害性や、スパコン運用データの分析のようなものも含まれます。 世界のHPCの研究者が集結して交流を行う最大の会議といわれます。
SCの査読プロセスは最大で2回のリバッタルを含み、採択された後に提出するカメラレディではリファレンス抜きで最大12ページの論文となります。例年の採択率は20%前後で、今年の採択は87/339 (25%) と採択率だけみるとやや高めでした。 ちなみに、第一著者で日本人と思われる名前の人はざっと見た感じだと3人だけでした。
SCは会議だけではなくて、後述するエキシビジョンを始めとしたお祭り要素も大きく来場者は一万人を超えます。
#SC19 by the numbers: @Supercomputing #HPC pic.twitter.com/q6PMX0inXQ
— Intersect360Research (@Intersect360) November 19, 2019
会場はアメリカで発表されることが恒例になっていて、今年は デンバーが開催地に選ばれました。 デンバーは内陸で乾燥していて、年間300日が晴れという気候です。 僕はじめじめしているのが無理なので、喉がちょっと痛くなったことを除けば、毎日最高な気分で過ごせました。
今年のスケジュールは11月17日から22日までの6日間で、コロラド会議場で開催でした。 会期中はデンバーのメインストリートのいたる所にSCの旗が立っていて、SCが巨大な会議であることが感じられてワクワクしました。
6日間のうちの最初の2日間はチュートリアルで、HPCに関係する有名な言語、システム、ツールなどについてのハンズオン付きの講義を、開発者直々に受けることができます。 チュートリアルの種類は30種類くらいあって選ぶのになかなか苦労しましたが、聞けなかったものについてもスライドが配布されるのがうれしいです。
僕は迷った末、OpenMPのタスク並列、HPC向け性能分析ツールの二つのトピックを選択しました。 どちらもなんとなく知ってはいたものの腰を据えて勉強したことはないトピックだったのですが、スライドが丁寧で基本的なところから説明してくれるので理解がはかどりました。 具体的にはOpenMPのtask dependency, tasklopp construct、性能分析ツールの方はTAU, Scalasca, Score-Pなどの使い方を学べました。
次の3日間はメインのテクニカルペーパーの発表で、今年は（ほぼ）3トラックで開催でした。 トラックと論文一覧はおなじみのdblpをみるとわかりやすいと思います。 SCには専用のアプリがあるのですが、どのトラックに出席するか決める際に非常に有用でした。 発表者の中には超高速で話す話者がいたのですが、たどたどしく話すノンネイティブと思われる質問者に対してもそのスピードを緩めることをしなかったので恐ろしいなあと思ったのを覚えています。面白かった論文紹介は記事の後半に書きます。
最後の残りの1日は午前中のみのワークショップ、というスケジュールです。 他に、BoF(Bird of a Feather)というあるトピックについて専門家が語りあうコーナーもあり、白熱した議論が繰り広げられます。 ユーザーレベルスレッドと、MPIライブラリの一つであるmpichなどのBoFに参加したのですが、研究者が未来を語る能力はすごいなあという気持ちになりました。
SCの楽しいイベント
SCはメインのテクニカルペーパーの発表が素晴らしいのはいうまでもないですが、その裏側でエキシビジョン展示が派手に行われることで有名です。 エキシビジョンでは企業や大学がブースを設置して、新製品の展示や研究成果の発表を行っています。
でかいコンピュータやその部品の展示に囲まれてぶらぶらしているだけでテンションが上がって楽しいです。 手品をやっていたり、インタラクティブな催しものをやっているブースもあり、活気にあふれています。 ランチの時間帯に行くと、色々食べながら話を聞けるらしいと聞きました。
せっかく海外に来たからにはと思って色々と話しかけては見ましたが、やはり商談がメインであり、学生はメインターゲットではないなあという印象でした。 「大学で買うことがあったら連絡してくれ」みたいなことを言われてしまい、冷やかしですまんな、という気持ちになりました。
SCの公式イベントが終わった後には、毎日どこかしらの企業が無料で参加できるパーティを開いていて、またこれも楽しいです。 僕はスパコンのCray, インターコネクトのMellanoxのパーティに参戦しました。 Microsoft, Intel, Nvidia, AMDなどのお偉いさんの挨拶を聞いて、スケールのでかさにぶち上がったりしていました。
余興として現地のコメディアンが出てきて、小道具無しトークオンリーのコメディを一時間弱ほどやってましたが、一ミクロンもわからなかったです。 国際会議という世界各地から人が集まるイベントではあるのですが、こういうのをチョイスするあたり、HPCがアメリカが中心ってことなんでしょうね。
TOP500
SCは世界の高性能なスパコンランキングのTOP500が発表されることも大きな特徴です。 発表される指標は、HPL, HPGC, Green500の三種類です。
まず、HPLは古くからスパコンランキングの測定に使われている指標であり、連立一次方程式のベンチマークを実行した時のFlops（浮動小数点演算数/sec）を測定するものです。狭義のTOP500といえばこれのことを言います。 ただし、HPLは密行列を使って計算を行うので計算律速になり、最近のアプリケーションの傾向にあっていないとの指摘もあるようです*1。
それに対してHPCGはやや新しい指標となります。 HPLと同じく連立一次方程式を解くのですが、使われる行列が疎行列でメモリ律速となってそれほど性能が出ないようになっています。 実際、今年のランキングの理論性能比を見てみると、 HPLは70%以上出ているものがあるのと比較して、HPCGは1%前後のものが多い印象です*2。
今年の結果のリンクを貼っておきます。
November 2019 | TOP500 Supercomputer Sites
HPCG - November 2019 | TOP500 Supercomputer Sites
今年のHPLとHPCGのランキングの結果は、トップの3つが去年と変わらない、IBM Summit（アメリカ）, Sierra（アメリカ）, Sunway TaihuLight（中国）という結果になりました。 デナードスケーリングが終わりスパコンの進歩がゆっくりになっていて、スパコンそのものの寿命が延びている、といった話をされていた気がします。 日本からは、産総研のABCIが8位、東大のOakforest-PACSが15位にランクインしています。
残る指標はGreen500ですが、電力効率 (GFlops/watts) でランクづけします。 今年は富士通の富岳がトップになったことがニュースになりました。
正確にいうと富岳はまだ稼働していないので、そのプロトタイプであるA64FXでランクインしているという形になります。めでたいですね！
SC19論文紹介
ここからはSC19の論文紹介のコーナーです。二本の論文を専門外の人にも理解できるようにじっくり解説します。
Compiler Assisted Hybrid Implicit and Explicit GPU Memory Management under Unified Address Space*3
一つ目の論文は、GPUのユニファイドアドレス空間の管理についてのコンパイラ支援についての論文です。
ディープラーニングの流行によって読者の皆さんの中にもGPUを使ったことのある人も多いとは思いますが、 具体的にどのようにメモリを管理しているかはご存知でしょうか？ 一般的に、DLフレームワークでは隠されている部分なのですが、GPUで計算をするには明示的にCPUとのデータのやり取りをする必要があります。 つまり、まずCPUからGPUに必要なデータを送り、GPUで計算を行い、CPUに計算結果を送り返すという手続きを踏まなくてはならないわけです。
ただし、それはなかなかにGPUプログラミングコストが大きいので、最近のGPUアーキテクチャではCPUとGPUでメモリ空間を共有するユニファイドメモリ (unified memory) という種類のメモリが導入されています。ユニファイドメモリを用いると、プログラマはCPUとGPUの間でのデータの通信を明示的に記述する必要がなくなり、単一のデバイスを使用している感覚でプログラミングを行うことができます。ただし、ユニファイドメモリを使用したとしても通信自体はどこかでやらなくてはならないわけで、それはシステムが暗黙のうちに担うことになります。CPUからGPUへの通信を例に説明すると、GPUで計算を行っている時に必要なデータがないとわかるとその都度エラーを発生してやって、必要なデータを送るようにCPUに依頼するというようになるのですが、そのエラーをページフォルト (page fault) と呼び、MMUと呼ばれるハードウェアの機構で検出します。
このように有用なユニファイドメモリなのですが、主に二つの性能劣化の原因が存在します。一つ目は、先ほど説明したページフォルトのオーバーヘッドによるものです。二つ目は、GPUのメモリ量には限りがあって、それを上回る量のデータのやり取りを行う時に生じるスラッシングという現象によるものです。GPUのメモリをフルに使用している時に、ユニファイドメモリを通してさらにGPUへのメモリ転送が要求された時には、何かしらのデータをCPUに送り戻してあげなくてはなりません。通常はそのデータは最後に使用された時刻が最も遅いものが選ばれるのですが (LRUアルゴリズム) 、その選択と実際のワークロードがマッチしなかった場合にはある種のデータがCPUとGPUの間を頻繁に行き来することになります。これをスラッシングと呼び、そのデータに関する処理が極端に遅くなることになります。
この二つの性能劣化の原因を解消するために、コンパイラの手助けを借りて、ユニファイドメモリを使用して書かれたステートメントをいい感じの明示的な通信に変換して性能を向上させよう、というのがこの論文の提案です。ただ闇雲に変換しただけでは元のLRUにも勝てないので工夫する必要があるのですが、ここでは変数のアクセス密度 (access density) と再使用距離 (reuse distance) を考慮します。アクセス密度とは配列に対して定義されて、配列全体のうち実際にアクセスされる割合として計算されます。また、再使用距離とは、同じ変数が一度アクセスされて再びアクセスされるまでの距離のことで、通信の単位をまたいだ個数のようなものとして計算されます。コンパイラはこれらの情報をユニファイドメモリの使われているソースコードから抽出することで、使用される頻度の高いデータを積極的にGPUに残し、そうでないデータはCPUにすぐ書き戻すような明示的な通信に変換します。通信を明示的に発行するということはページフォルトの機構を使用しなくてよいことを意味し、また先ほど説明した情報を利用した効率的な通信の変換によってスラッシングを減らすことができるため、性能劣化を抑えることができるわけです。
最後に評価結果（の一つ）を載せておきます。miniViteというアプリを実行した時の実行時間を比較しているのですが、ユニファイドメモリをナイーブに使った場合（赤）と比較して、提案手法（紫）は性能が向上しています。
ComDetective: A Lightweight Communication Detection Tool for Threads*4
二つ目は、共有メモリ上のスレッド間通信を検知して可視化するツールであるComDetectiveについての論文です。
現代の計算機で性能を出すためには並列計算が必須であり、今どきのCPUはコアと呼ばれる演算ユニットを複数持ってることが普通です。 並列計算の際には、CPUの各コアにそれぞれ計算を割り当てることになりますが、その計算のひとまとまりのことをスレッド (thread) と呼びます。 CPUの各コア間ではメモリは共有されているので、スレッド同士がお互いの計算結果にメモリを通してアクセスしながら計算を進めていきます。
ただし、並列プログラムは予想したほど性能が出ないということは往々にしてありがちであり、そのために性能を分析するための専用のツールが不可欠です。 この論文は、スレッド間の通信に関する情報を通信行列 (communication matrix) の形で提供するツール、ComDetectiveを提案しています。 通信行列とは、それぞれのスレッドのペアが行なった通信の回数をカウントしたものであり、LULESHというアプリを四つの別々の条件で測定してヒートマップとして可視化したものが下の図です。濃くなっている部分に対応するスレッドのペアが通信を多く行なっているということを意味しています。
さて、共有メモリによるスレッド間通信は暗黙のうちに行われるため、検出することが簡単ではありません。似たようなことをやっている既存のツールは、シミュレーションや計測のためのコードを埋め込むといった手法を用いていますが、オーバーヘッドが大きかったり、正確さに欠けているという点で実用的とはいえません。 ComDetectiveは、ハードウェアに備わっているPMU (Performance Monitoring Unit) という計測用のユニットと、x86プロセッサに付随しているデバッグレジスタ (debug register) と呼ばれる特殊なレジスタを用いて、軽量に通信行列を生成する手法を導入し、軽量かつ正確にスレッド間通信を検出します。
まず、PMUは、ハードウェアのイベントをカウントするユニットであり、ロードストアといったメモリアクセスやCPUサイクルなどをカウントすることができます。 PMUのカウントがある一定の回数を越えると割り込みが生じて、コールバック関数を通してその瞬間の情報を記録することができます。
ComDetectiveでは、PMUで割り込みが生じた時に（スレッドID、メモリアドレス、メモリアクセス時刻）についての情報を記録しておき、測定が終了したあとに一つのアドレスに注目してアクセス時刻で並び替えることで、スレッド間の通信を検出します。 しかしそれだけでは検知できる通信が限られてしまうことになり、ツールとしては不十分なものになります。 というのも、PMUでの割り込みはあくまでメモリアクセスの回数がある閾値を上回った時にのみ生じるので、全てのロードストアについての情報が記録されるのではないためです。 したがって、PMUを通して測定されるサンプリングされた情報だけからでは、 スレッドをまたいで複数回検出されるような、頻繁にアクセスされるアドレスに関する通信のみしか検出できないことになります。
そこで、サンプリングされる頻度の少ないメモリアドレスに関する通信を検出するのに用いるのが、デバッグレジスタです。 デバッグレジスタは格納された特定のアドレスを監視して、そのアドレスにプログラムカウンタが到達したりメモリアクセスが生じた時に、同様に割り込みを生じさせることができます。
ComDetectiveでは、PMUで割り込みが生じた時には集計用のログを残すだけではなく、そのアドレスをデバッグレジスタにも格納します。 そのアドレスに対して再びメモリアクセスが生じた時には、デバッグレジスタが割り込みを発生させるので、そのタイミングで通信を検出します。 PMU単体だと、二回目のアクセスの瞬間に、再びPMUの割り込みが偶然に生じていないと通信を検出できないのですが、デバッグレジスタを用いることで確実に二回目にアクセスする瞬間を捉えることができます。 このようにPMUとデバッグレジスタを組み合わせることで、ComDetectiveは軽量にスレッド間通信を検出します。
少し話がずれますが、システムがメモリ管理をキャッシュライン (cache line) と呼ばれる単位で行なっている都合上、各スレッドがキャッシュラインに含まれている別々のメモリにアクセスする際にも、キャッシュライン単位で通信が行われてしまうことがあります。 これをFalse Sharingと呼び、共有メモリでプログラミングをする際に注意を払わなくてはならない性能劣化の原因です。 ComDetectiveはスレッド間のそれぞれの通信が、False Sharingであるかどうかを区別して検出するということができるので、よりユーザーに対して有益な知見を提供することができます。
デンバー散策
最終日の午後の余った時間で、Red Rocksという野外劇場に行ってきました。車で30分ほどだったのですが、Uberがとても安くて便利だったので感動しました。
あとは夜に食べたバカでかい肉を載せておきます。
おわりに
トップカンファレンスに参戦するのは初めてだったので、毎日が刺激的であっという間でした。
それから、やはり自分の英語力はまだまだであることが身に沁みました。 早口ネイティブイングリッシュ、もごもごイングリッシュはほぼ何もわからなかったです。 まあ訛りによって英語の聞き取りやすさが全然違うというのがわかったのは実に面白かったのですが、地道に精進するしかないなあという気持ちです。
SCは日本人が多い、それも発表しない日本人が多いという話を聞いていましたが、実際その通りでした。 僕もその一員なのですが、行くことを許可していただいた指導教官に感謝です。
いつか何かしら発表するものを持ってSCに行きたいですね（メインペーパーで発表した同期をみながら）。
長くなってしまいましたが、読んでいただきありがとうございました。
*1:https://www.top500.org/news/top500-meanderings-hpcg-gains-steam-as-alternative-benchmark-for-supercomputers/
*2:https://www.hpcg-benchmark.org/custom/index.html?lid=155&slid=302
*3:Li, L., & Chapman, B. (2019). Compiler assisted hybrid implicit and explicit GPU memory management under unified address space. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis on - SC ’19 (pp. 1–16). New York, New York, USA: ACM Press. https://doi.org/10.1145/3295500.3356141
*4:Sasongko, M. A., Chabbi, M., Akhtar, P., & Unat, D. (2019). ComDetective: A Lightweight Communication Detection Tool for Threads. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis on - SC ’19 (pp. 1–21). New York, New York, USA: ACM Press. https://doi.org/10.1145/3295500.3356214
