Linuxでinodeが枯渇した場合にどうやって調査するか

こんにちは。並河(@namikawa)です。

最近はすっかり暖かい日が続いておりまして、花粉が飛散して本当に悲惨な感じになってしまっているアカウントがこちらになります。

さて、近頃は、GCPへの移行を終えたり、新しいメンバーが続々とジョインしてきてくれていることもあり、本業のインフラ職人業が随分と減ってきていて、やっぱり最近力を入れている採用の話を書こうかなと思ったのですが、そういえば前回は採用向けの話（アスタミューゼの開発組織と採用に関するQAアレコレ）を書いたところだったので、今日はLinux運用環境での小ネタでも書こうかと思います。

「なぜかサーバに書き込めません！」

ある日、とあるサーバのディスク関連のアラートが飛んできて、エンジニアがサーバの状況を確認したところ、ディスクの容量には空きがあるが、なぜか書き込めないという状態になっていました。

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.9G  5.5G  3.9G  59% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            286M  8.0K  286M   1% /dev
tmpfs            59M  348K   59M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            295M     0  295M   0% /run/shm
none            100M     0  100M   0% /run/user

dfコマンドでディスクの使用量を確認するも空き容量はまだ残っている感じ。 エラーを確認すると "No space left on device" とな。

# df -i
Filesystem     Inodes  IUsed IFree IUse% Mounted on
/dev/sda1      655360 654754   606  100% /
none            75426      2 75424    1% /sys/fs/cgroup
udev            72973    405 72568    1% /dev
tmpfs           75426    327 75099    1% /run
none            75426      3 75423    1% /run/lock
none            75426      1 75425    1% /run/shm
none            75426      4 75422    1% /run/user

というわけで、定番の inode 枯渇問題でありました。

たくさんのファイルがどこにあるのかを探す

やり方は色々あるかと思うのですが、地道にルートからたくさんあるディレクトリを探していきます。 地味なやり方ですが、まずは1階層目のレベルで、どこの配下に大量のファイルがあるか探索します。

# find / -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -nr
 489278 usr
  14308 lib
   3287 var
   1818 data
    826 etc
    293 boot
    130 sbin
    128 bin
     94 home
      5 root
      3 tmp
      1 swap

こんな感じで、"/usr"配下のどこかにたくさんファイルが存在していることがわかりました。 あとは同じ要領で機械的に2階層目・・・と探していけばよいです。

# find /usr -xdev -type f | cut -d "/" -f 3 | sort | uniq -c | sort -nr
 460742 src
  15060 share
  12806 lib
    544 bin
    121 sbin
      5 include

"/usr"配下を対象に2階層目を探索した結果がこちら。"/usr/src"にたくさん溢れている、、、というところでピンときますね。

# ll /usr/src
total 188
drwxr-xr-x 47 root root 4096 Dec 15 06:45 ./
drwxr-xr-x 10 root root 4096 Nov 14  2015 ../
drwxr-xr-x 24 root root 4096 Jul 15  2016 linux-headers-3.16.0-77/
drwxr-xr-x  7 root root 4096 Jul 15  2016 linux-headers-3.16.0-77-generic/
drwxr-xr-x 27 root root 4096 Nov 21 06:33 linux-headers-4.4.0-101/
drwxr-xr-x  7 root root 4096 Nov 21 06:33 linux-headers-4.4.0-101-generic/
drwxr-xr-x 27 root root 4096 Dec  8 06:50 linux-headers-4.4.0-103/
drwxr-xr-x  7 root root 4096 Dec  8 06:50 linux-headers-4.4.0-103-generic/
drwxr-xr-x  7 root root 4096 Dec 15 06:45 linux-headers-4.4.0-104-generic/
drwxr-xr-x 27 root root 4096 Feb 23  2017 linux-headers-4.4.0-64/
drwxr-xr-x  7 root root 4096 Feb 23  2017 linux-headers-4.4.0-64-generic/
drwxr-xr-x 27 root root 4096 Mar  9  2017 linux-headers-4.4.0-66/
drwxr-xr-x  7 root root 4096 Mar  9  2017 linux-headers-4.4.0-66-generic/
drwxr-xr-x 27 root root 4096 Mar 16  2017 linux-headers-4.4.0-67/
drwxr-xr-x  7 root root 4096 Mar 16  2017 linux-headers-4.4.0-67-generic/
drwxr-xr-x 27 root root 4096 Mar 28  2017 linux-headers-4.4.0-70/
drwxr-xr-x  7 root root 4096 Mar 28  2017 linux-headers-4.4.0-70-generic/
drwxr-xr-x 27 root root 4096 Mar 31  2017 linux-headers-4.4.0-71/
drwxr-xr-x  7 root root 4096 Mar 31  2017 linux-headers-4.4.0-71-generic/
drwxr-xr-x 27 root root 4096 Apr  5  2017 linux-headers-4.4.0-72/
drwxr-xr-x  7 root root 4096 Apr  5  2017 linux-headers-4.4.0-72-generic/
drwxr-xr-x 27 root root 4096 Apr 25  2017 linux-headers-4.4.0-75/
drwxr-xr-x  7 root root 4096 Apr 25  2017 linux-headers-4.4.0-75-generic/
drwxr-xr-x 27 root root 4096 May 18  2017 linux-headers-4.4.0-78/
drwxr-xr-x  7 root root 4096 May 18  2017 linux-headers-4.4.0-78-generic/
drwxr-xr-x 27 root root 4096 Jun  7  2017 linux-headers-4.4.0-79/
drwxr-xr-x  7 root root 4096 Jun  7  2017 linux-headers-4.4.0-79-generic/
drwxr-xr-x 27 root root 4096 Jun 20  2017 linux-headers-4.4.0-81/
drwxr-xr-x  7 root root 4096 Jun 20  2017 linux-headers-4.4.0-81-generic/
drwxr-xr-x 27 root root 4096 Jun 29  2017 linux-headers-4.4.0-83/
drwxr-xr-x  7 root root 4096 Jun 29  2017 linux-headers-4.4.0-83-generic/
drwxr-xr-x 27 root root 4096 Jul 25 06:41 linux-headers-4.4.0-87/
drwxr-xr-x  7 root root 4096 Jul 25 06:41 linux-headers-4.4.0-87-generic/
drwxr-xr-x 27 root root 4096 Aug  4 06:32 linux-headers-4.4.0-89/
drwxr-xr-x  7 root root 4096 Aug  4 06:32 linux-headers-4.4.0-89-generic/
drwxr-xr-x 27 root root 4096 Aug 12 06:55 linux-headers-4.4.0-91/
drwxr-xr-x  7 root root 4096 Aug 12 06:55 linux-headers-4.4.0-91-generic/
drwxr-xr-x 27 root root 4096 Aug 16 06:35 linux-headers-4.4.0-92/
drwxr-xr-x  7 root root 4096 Aug 16 06:35 linux-headers-4.4.0-92-generic/
drwxr-xr-x 27 root root 4096 Aug 29 06:34 linux-headers-4.4.0-93/
drwxr-xr-x  7 root root 4096 Aug 29 06:34 linux-headers-4.4.0-93-generic/
drwxr-xr-x 27 root root 4096 Sep 19 06:32 linux-headers-4.4.0-96/
drwxr-xr-x  7 root root 4096 Sep 19 06:32 linux-headers-4.4.0-96-generic/
drwxr-xr-x 27 root root 4096 Oct 11 06:49 linux-headers-4.4.0-97/
drwxr-xr-x  7 root root 4096 Oct 11 06:49 linux-headers-4.4.0-97-generic/
drwxr-xr-x 27 root root 4096 Oct 31 06:39 linux-headers-4.4.0-98/
drwxr-xr-x  7 root root 4096 Oct 31 06:39 linux-headers-4.4.0-98-generic/

はい、このサーバはセキュリティ関連の自動アップデートが動いているサーバでしたね・・・。

ということで、不要なパッケージを apt-get purge 等で綺麗にしたのでした。

おわりに

弊社には大量のデータがあるので、本当はファイルがたくさんあって大変、みたいな話に無理やり結びつけようとも思ったのですが、そもそも基本的には各種データストアに入れているし、Rawデータの置き場はGCSのお世話になっているので、inodeに影響を及ぼす様なことは基本的にはありません。

ということで、割とありきたりなネタで恐縮でしたが、何かのお役に立てれば幸いです。

最後に、弊社ではエンジニア・デザイナーを絶賛大募集しておりますので、少しでも気になれば、カジュアルにランチでもしながらお話ししましょう。疑問・質問などございましたら、お手数ですが (@namikawa) まで気軽にDM等いただければと思います。

それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

アスタミューゼ開発部の新人育成の話

こんにちはnishikawaです。今年度もあと少しで終了です。花粉が辛い今日この頃ですが、巷では新年度に向けて色んな仕事が舞い込んできているのではないでしょうか。

さて、新年度といえば学生が社会人になる時期でもあります。新しい環境下で始まる社会人生活に緊張や不安を抱いている新社会人も中には居ることでしょう。

一方、採用側の企業はというと、こちらも色々と緊張していると思います。「えっ？採用側も緊張するの？」と思うかもしれないですが、『新人が会社になじむにはどうしたらいいのか』、『研修はうまく行くのか』等々、心配事は尽きません。nishikawaの上司は新しい人が入る度に最初のコミュニケーションをどうしようか凄く考えています。それは周りにいる同僚も同様で新人の方が初めて出社した日はオフィスにいつも以上の緊張感があります。

そんなアスタミューゼの開発部ですが、今年はIT業界での業務経験がない方が入社されました。その方は大学も文系卒でプログラミングとは無縁の経歴だったため、新人を教育するにあたり、研修内容をどうしたらいのかというところが部の一番の悩みでした。

そこで、私が提案させていただいたのがジャストシステムさんの開発の方が利用されているJava100本ノックというドキュメントです。これは、Javaを利用する上で必要となる知識や、よく利用するライブラリ、フレームワークについて学習するために作られた問題集です。

Java 100本ノック: https://github.com/JustSystems/java-100practices

この問題集、GitHubに公開されており、初歩的なJavaの操作から言語仕様、コアAPI、ライブラリ、フレームワークととにかく基本を意識した問題が多いのが特徴です。

この問題集を今回弊社では試用期間中に最低2巡することを目標にカリキュラムを組み現在実施中です。

今回は弊社でやっているJava 100本ノックの進め方を記載したいと思います。

• 1巡目 (現在実施中)
  • とにかく問題を流しでやってみる。分からなかったらすぐ解答・解説を読む
  • 問題文、解答・解説を読んでも分からないところ、それ以外の箇所での分からないところはOJT指導者に質問する
• 2巡目
  • 1巡目で得た知識を踏まえて問題を解く
  • コーディング規約を意識する
  • テストを書く

1巡目

1巡目はとにかく全体を俯瞰させるためにとにかく問題をやらせています。少し考えて何も閃かなかったらすぐに解答と解説を読むことを推奨し、その上で分からないことを些細なことでも質問させています。

プログラミング経験がないということなので、ターミナルの使い方やbashの話などJavaには全く関係ないことについても質問を受け付け、それに対して実例も見せながら解説しています。1日に解説している時間は2〜3時間程度で、その時間で収まるように新人の方には質問の要点を絞らせ、まとめさせることを強く意識させています。

1巡目のねらいは、Javaの全体像の把握と問題・課題の深掘りによる問題解決能力の育成があります。問題を解いてJavaを理解することは重要ですが、それよりも何が分からないのか、分からないのは何が問題になっているからなのかの把握と追求が一番重要だと考えております。

2巡目

1巡目を踏まえて、今度はJavaを集中して体得するのがねらいです。そのため、2巡目では問題文が求めていることを精査し、それを実現するための手法を考えることに重きを置いています。また、2巡目ではすべてのコードに対してテストコードを書いてもらおうかと考えています。

Java 100本ノックをやってみての感想

1ヶ月間、Java 100本ノックを新人にやらせてみて振り返ってみると色んなものが見えてきました。

良かった点

• Java のコーディングの仕方、機能の使い方が分かる
• 業務上では使わない機能も問題に取り上げられている
• ちゃんとやればやるほど、教える側と教わる側、それぞれの勉強になるような問題が多い

Java 100本ノックの効果は教える側と教わる側がそれぞれいるときに最も享受できると思います。教える側と教わる側がそれぞれ顔を付き合わせて問題に取り組むことで両者とも知識が深められます。

ポイントは

• 問題の意図をちゃんと理解する
• 解答・解説を理解し、コードを1行ずつしっかり追って理解する

です。nishikawaも色々と教える上で分からないことに直面する機会が多かったのでとても勉強になりました。

良くなかった点

• プログラミング初心者向けではない
• Javaを独学で勉強する場合には効果が薄い

良くなかった点はこの問題集は初心者向けに作られていないところだと思います。問題自体はある程度Javaもしくは何かのプログラム言語を使ったことがある人を前提にして居る節があるため、本当の初心者がやるには少し辛いと思います。ですので、この問題をやる場合はJavaの入門書を事前にある程度やっていることをお勧めします。

また、独学でやる場合理解が中途半端になる可能性があるので注意が必要だと思います。学習全般に言えると思いますが、クロスチェックはある程度必要なので、これも例外ではないと思います。

結局どうだったのか？

現在、1巡目を行なっていますが、結論から言うとかなりの成果が出ています。新人の方がとても優秀だと言うこともありますが、分からないところへの分析がよくできるようになってきているため質問が問題を解くごとに少なくなっています。

問題を解くことに関しては、まだ知識や経験が不足しているため、自力では難しいですが、コードを読んで分からない箇所を自信で調査し独力で理解するという行動ができるようになってきています。

以上を踏まえると、申し分ない成果が出ていると思います。しかし、今回新しく入った新人の方が優秀だということも多分にあるため、今後も様々な育成をやっていく中でastamuse開発部の育成方法をちゃんと確立できるように試行錯誤していきたいと思います。

デザイナーもデブサミに行った方がいい理由をざっくりまとめてみた

こんにちは、@YojiShirakiです。デザイナーです。

先日、デブサミ2018がありましたね。当日のタイムラインでは各セッションに関してのツイートが流れ、はてブでは資料情報などがホットエントリーに入っており、今年も盛況だったことが窺えます。私はというと、突如の高熱（インフル）で全く起きれずスマホでタイムライン追って様子を見ていました。

私はデザイナーですがデブサミなどエンジニア向けの大型のイベントは極力参加するようにしていて、毎回かなりよい感触を得ています。そして毎回「これはデザイナーも来た方がいいのでは？」と思っています。

そこで今回は、デザイナーである私が過去数年に渡ってデブサミに参加した経験から、デザイナーがデブサミに行った方がいい理由をまとめました。ぜひご覧ください。

デブサミはエンジニアのためだけのイベントではない

まず大前提ですがデブサミ（Developers Summit）はもはやエンジニアだけのイベントではありません。名前だけみるとエンジニアのためのイベントに見えますが、決してそんなことはありません。試しに先日のデブサミ2018のセッションをご覧ください。

• Developers Summit 2018　セッション

ざっと見ただけでもエンジニア以外にも通じるセッションがいくつもあります。

• カイゼン・ジャーニー 〜たった一人からはじめて、「越境」するチームをつくるまで〜
• 婚活サービスにおけるシステム×サービスのイノベーション
• 多様なビジネスドメイン、サービスフェーズが混在する中での組織戦略と技術戦略
• イノベーションを起こす開発チームの作り方

どれもプロジェクトマネージャーやプロダクトマネージャーにとっても聞く価値がある内容ですし、デザイナーにとってももちろん参考になる内容です。

他にもこんなのもあります。

• NRIの働き方改革 - 開発スタイルから文化まで変えた軌跡 -
• リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく

最近ホットな働き方についてのセッションですね。エンジニアリングというのはあらゆるところに関係するので、デブサミというのも決して技術だけの話に留まらないのです。

情報収集効率が良い

デブサミなどの大型イベントは情報収集効率が非常に良いです。先ほど紹介した通り非常に多岐にわたる内容を2日間でまとめ聞きすることができます。仮にもしこれを別々の勉強会で聴こうと思ったら相当な時間をかけねばなりませんが、デブサミであれば2日で済みます。また空き時間は休憩スペースで仕事できるのでリモートで作業しながらセッションに参加ということもできます。

プレゼンの参考にも

また、デブサミで発表される内容は相応に吟味されているものが多いので情報の質も高いです（ハズレもありますが）。有料セミナーほどではないかもしれませんが、控え目に見てもエンジニアイベントで最大規模のものなのでプレゼンテーターもよく練習しています。時間の使い方、スライドの見せ方、ウケの取り方など、プレゼンテーションの参考になります。

今、技術で何ができて何が難しいのかを知れる

デブサミでいろいろなセッションを聞くと「今は、ここまでできるんだな」とか「これはまだ技術的に難しいのか」といった感触を肌で感じられます。これが本当にありがたく、デザイナーにとっては引き出しの数が増やすネタになるし生産性向上にも繋がります。

例えば、サイトにチャットのシステム埋め込んでユーザーの体験性を向上したり、機械学習を利用してユーザーに対してよりよい情報を提供する、など技術的に実現可能なネタを理解できていればサービスの改善幅が格段に広がります。さらに、デブサミではそう言った話を実際の体験談として教えてくれるので、先回りして失敗を回避でき、実現可能性を高めてくれます。

また生産性でいえば、ここ数年浸透したDevOpsの動きなどに代表されるような事例は非常に参考になります。チャットオプスや、ツール導入によるコミュニケーション品質の向上・作業時間の圧縮、プロジェクト成功のコツなど。

弊社でもチャットオプスは導入していて非常に助かってますが、こういった事例は実際に話を聞いてみると、わかることもたくさんあります。

他社のサービス開発の裏側を見ることができる

他社のサービス開発ってどうなってるか興味ありませんか？自社ではこうしているけど他ではどうしているんだろう、と。こういった話はデブサミでは本当にいろいろな方が話してくれています。「スクラムやったけどうまくいかなかったよ」とか「trello使ってこんな感じでプロジェクト進められました」など。

また、エンジニアとデザイナーの共生について垣間見ることもできます。エンジニアからはデザイナーがどういう風に見えているのか、またどういう風に巻き込もうとしているのか。こういった自分たちに対しての第三者の目線を知る機会としてもデブサミは非常に良い場所になっています。

デザインとデザイン業界の相対化

デブサミに出てみると「なるほどエンジニアの世界はそうなっているのか。翻ってデザインの世界はどうだろう？」と考えさせられます。決してデザインの世界を揶揄するわけではありませんが、そうやって相対化することで見えてくることは必ずあります。それはデザインの強みや弱み、デザイン業界の課題やアドバンテージなど。

例えば、昨年の11月にAdobe Maxがありました。私も参加したのですが、正直面白いところもあったけれど残念なところも少なくありませんでした。デブサミなどと比較すると「もっとこういう要素があった方が良かったな」と思える点が多々ありました。こういう風に考えられることも（デブサミに限らず）、自分の領域とは違うところに顔を出すメリットなのかと思います。

エンジニアと話せるようになる

これはとても大きいですね。普段のコミュニケーションが変わってきます。

私はもともとコード書くのが好きというのもあり隔てなく話せる方だと思いますが、デブサミやGCP Next Tokyo（Googleの主催する大型イベント）に参加してエンジニアのみんなと一緒に先端の情報に触れるとまた格段と話しやすくなります。

• 「あのセッションで聴いた内容いいよね」
• 「もっとこういう技術使ってワークフロー改善したらいいかもね」

と言ったような。

あとはいくつものセッションを聴いていると、だんだんとエンジニアがどういう考え方をして何に重きを置くのかということを体感として理解できるようになります（そう信じている、という方が正しいかもしれませんが）。こういった共通感覚を醸成できるのも大きな収穫になると感じます。

いずれにせよ、エンジニアとデザイナーは協力することで良いものを生み出していくので、お互いのことを知るというのは大事という、至極当然な話なのですが。

おわりに：デザイン以外の領域にも触れるマインドがとても大事

デザイナーは気づいたらコミュニティーの内側に閉じこもってしまいがちです。自分の世界を大事にするというか。でも、私たちデザイナーが相対するのは「人」ですから、閉じこもらずに様々な領域、少なくても自身の近接領域であるエンジニアリングやマーケティングの世界を知ることを是非大事にしてもらいたいな、と思います。また、日々の発想を豊かにするためにまったく違う領域に興味を持つ好奇心は常に高く持ちたいな、と。

では、本日も最後までお読みいただきありがとうございました。

例によって当社では一緒に開発してくれるメンバーを募集しております。カジュアル面談も随時行っておりますので、「ちょっと話聞きたい」という方は、このブログのサイドバー下にあるアドレスか@YojiShirakiあたりにDMいただければと思います。採用サイトもありますので↓↓↓のバナーから是非どうぞ！

（過去記事）

• デザイン採用担当はポートフォリオで何を見ているか、何が見えているか？
• 広告費用を自動取得し100時間分の作業をなくす話
• デザイナーが「言葉」についてちょっと真面目に考えてみた
• お手軽に英文文書にメタ情報を!!Pythonでgensimを使ったLDAに挑戦してみた。
• 英文の自然言語処理におススメ！お手軽なPolyglotを使ってみた。