Modern Systems Programming with Scala Native: Write Lean, High-Performance Code without the JVM

いまだScala 2.11までのサポートしか提供されていないなど開発が停滞気味のScala Nativeですが、最近書籍が出たということで読んでみました。

仕事でScalaCLIツールを書くことがあるのですが、やはりJVMの起動時間のオーバーヘッドが気になるのでネイティブバイナリを作成可能な技術としてScala Nativeが気になってはいたのですが、最近はそういう用途であればGraalVMのネイティブイメージ生成機能の方が最新バージョンのScalaを利用できたり、使えるライブラリの自由度など様々な面で実用的だなぁと感じていました。が、この本を読んでScala Nativeに対するイメージが一変しました。そう、Scala NativeはScalaで書いたプログラムをネイティブ化するためのものではなく、ScalaC言語として使うためのものだったのです。そう考えるとScala Native対応ライブラリの少なさもデメリットにはなりません。Cライブラリを使えばいいのです。

この書籍ではポインタやメモリ管理、システムコールを活用したプロセス管理、ネットワークプログラミングなど、Scala Nativeによるシステムプログラミングの基礎が解説されています。中盤からはlibuvとlibcurlを使った非同期I/O、LMDBを使ったデータの永続化、最終的には簡単なものですがWebサービスを構築するところまでいきます。本書の中で使用されているScalaライブラリがJSON変換用のArgonautだけという事実がScala Nativeの性格を如実に表しているのではないかと思います。

サンプルコードの中にはScala的に若干微妙なものもあったりするものの、この書籍はそういうところを見るべきではないのは明らかなのですが、とはいえ正直なところ各サンプルを眺めていると果たしてこれはScalaで書く必要があるのだろうかという気持ちにならないこともありません。しかしZoneを使ったメモリアロケーションの自動化などScala Nativeならではの便利機能もありますし、FutureExecutionContextなど既存のScalaの抽象化インターフェースを活用しているサンプルもあったりするので、超高レベルなシステムプログラミング環境として密かに需要があったりなかったりするのかもしれません。

この本を読んでScala Nativeにも頑張って欲しい気持ちが出てきたので、日本時間の昨日から今朝にかけてオンラインで開催されたScala Love Conferenceでのこの書籍の著者であるRichard WhalingさんによるScala Nativeのセッションを楽しみにしていたのですが、残念ならタイムゾーン問題により該当のセッションまで起きていることができませんでした。セッションはすべて録画されているとのことなので動画が公開されるのを待ちたいと思います。

scala.love

みんなのJava OpenJDKから始まる大変革期!

Java 14もリリースされるとのことですが、最近の動向をちゃんと追えていないので学習のためと、最近ずっと自宅から仕事をしているので気分転換の読書も兼ねて最近発売された「みんなのJava」を読んできました。

すでに現場でJavaを活用している人向けに、Javaの最新情報がざっくりと把握できるという感じの内容で、Java 14までの変更点、OpenJDKディストリビューションJakarta EE、Micro Profile、GraalVM、最新のマイクロサービスフレームワークと旬な話題を識者の方々の要点を押さえた解説により短時間で把握することができて助かりました。ここから必要に応じて各トピックを掘り下げていけばよいかと思います。季節ものなので今読んでおくべきと思います。あと、紙が厚いです。

個人的にはやはりJava 14までの新機能、GraalVMが興味深いところです。しかしJava 8の時点ですでに感じていましたが、随分Javaも様相が変わったなぁという感じがします。すぐに最新バージョンを使える現場ばかりでもないとは思いますが、今後も色々と変化がありそうなのでしっかりキャッチアップしていかないといけないですね。

Scala、Picocli、GraalVMによるネイティブCLIツールの作成

以前、Scalaを使ってCLIツールを作るという記事を書いたのですが、やはりJVMベースのアプリケーションには起動時間のオーバーヘッドが付き物なのでちょっとしたCLIツールをScalaで書こうという感じにはなかなかなりません。そこで今回はPicocliというJava向けのCLIツール用ライブラリとGraalVMを使ってネイティブCLIコマンドをScalaで作る方法を試してみました。

github.com

sbtプロジェクトの作成

今回はPicocliのドキュメントで例として掲載されていたchecksumコマンドをScalaで実装してみます。まずは以下の内容でbuild.sbtを作成します。

name := "picocli-scala-example"

version := "0.1"

scalaVersion := "2.12.7"

libraryDependencies ++= Seq(
  "info.picocli" % "picocli" % "4.2.0"
)

checksumコマンドのソースコードはこんな感じです。JavaコードをそのままScalaに書き換えただけです。コマンドやオプションの情報をアノテーションで宣言するのですが、フィールドをvarで宣言しておかないといけないのがちょっと微妙かもしれないですね。

package com.github.takezoe

import java.io.Fileimport picocli.CommandLine._
import java.math.BigInteger
import java.nio.file.Files
import java.security.MessageDigest
import java.util.concurrent.Callable
import picocli.CommandLine

@Command(name = "checksum", mixinStandardHelpOptions = true, version = Array("checksum 4.0"),
  description = Array("Prints the checksum (MD5 by default) of a file to STDOUT."))
class CheckSum extends Callable[Int] {

  @Parameters(index = "0", description = Array("The file whose checksum to calculate."))
  private var file: File = null

  @Option(names = Array("-a", "--algorithm"), description = Array("MD5, SHA-1, SHA-256, ..."))
  private var algorithm = "MD5"

  override def call(): Int = {
    val fileContents = Files.readAllBytes(file.toPath)
    val digest = MessageDigest.getInstance(algorithm).digest(fileContents)
    printf("%0" + (digest.length * 2) + "x%n", new BigInteger(1, digest))
    0
  }
}

object CheckSum extends App {
  val exitCode = new CommandLine(new CheckSum()).execute(args:_*)
  System.exit(exitCode)
}

Annotation Processorの実行

PicoliではGraalVMによるnative-image対応のためにAnnotation Processorを使用したコード生成が必要です。Annotation Processorはpicoli-codegenという別ライブラリとして提供されているのでこれをprovidedで依存関係に追加します。

libraryDependencies ++= Seq(
  "info.picocli" % "picocli" % "4.2.0",
  // Add a line below
  "info.picocli" % "picocli-codegen" % "4.2.0" % "provided"
)

build.sbtに以下のような感じの設定を追加して、processAnnotationsタスクでAnnotation Processorが実行されるようにします。

lazy val processAnnotations = taskKey[Unit]("Process annotations")

processAnnotations := {
  val log = streams.value.log
  log.info("Processing annotations ...")

  val classpath = ((products in Compile).value ++ ((dependencyClasspath in Compile).value.files)) mkString ":"
  val destinationDirectory = (classDirectory in Compile).value
  val processor = "picocli.codegen.aot.graalvm.processor.NativeImageConfigGeneratorProcessor"
  val classesToProcess = Seq("com.github.takezoe.CheckSum") mkString " "

  val command = s"javac -cp $classpath -proc:only -processor $processor -XprintRounds -d $destinationDirectory $classesToProcess"
  runCommand(command, "Failed to process annotations.", log)

  log.info("Done processing annotations.")
}

def runCommand(command: String, message: => String, log: Logger) = {
  import scala.sys.process._
  val result = command !if (result != 0) {
    log.error(message)
    sys.error("Failed running command: " + command)
  }
}

なお、Picocliにはアノテーションを使わないAPIも用意されており、そちらを使用すればAnnotation Processorを使わなくてもネイティブイメージの生成に対応できます。

GraalVMのインストール

続いてGraalVMをインストールします。以下からGraalVMのCommunity Editionをダウンロードして適当なディレクトリに展開し、binディレクトリを環境変数PATHに追加しておきます。

github.com

ネイティブイメージの作成に必要なnative-imageコマンドは以下のようにして別途インストールする必要があります。

$ gu install native-image

ネイティブイメージの作成

sbtでのネイティブイメージの作成にはsbt-native-packagerを使用しました。

github.com

project/plugins.sbtに以下の設定を追加します。

addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.6.1")

また、build.sbtに以下の設定を追加し、GraalVMNativeImagePluginを有効にするとともにパッケージ作成時にprocessAnnotationsタスクが実行されるようにしておきます。

packageBin in Compile := (packageBin in Compile dependsOn (processAnnotations in Compile)).value

enablePlugins(GraalVMNativeImagePlugin)

これで準備は完了です。sbtを以下のように実行するとネイティブイメージが作成されます。

$ sbt graalvm-native-image:packageBin

ネイティブイメージはtarget/graalvm-native-imageディレクトリにプロジェクトと同じ名前で生成されます。試しに実行してみましょう。

$ ./target/graalvm-native-image/picocli-scala-example
Missing required parameter: <file>
Usage: checksum [-hV] [-a=<algorithm>] <file>
Prints the checksum (MD5 by default) of a file to STDOUT.
      <file>      The file whose checksum to calculate.
  -a, --algorithm=<algorithm>
                  MD5, SHA-1, SHA-256, ...
  -h, --help      Show this help message and exit.
  -V, --version   Print version information and exit.

こんな感じで動作します。

まとめ

ScalaとPicocliを使用してGraalVMでネイティブイメージを作成できることを確認できました。ScalaCLIツールを書きたいけどJVMの起動時間が気になるという場合には選択肢になるのではないかと思います。また、以下の記事ではdeclineなどScala製のライブラリを活用したGraalVMによるネイティブCLIアプリケーションの作成方法を解説されています。ライブラリの選択など参考になります。

msitko.pl

Scalaでのネイティブアプリケーションの作成にはscala-nativeという選択肢もありますが、活発に開発が行われているとは言い難い状況で現時点ではScala 2.11のサポートに留まっています。また、利用可能なライブラリもかなり限られており、実用にはちょっと厳しいかなという感じがあります。

この記事で試したプロジェクトは以下のGitHubリポジトリに置いてあります。

github.com

Scalatra 2.7.0をリリースしました

Scala用のSinatraライクなWebフレームワークScalatraの最新バージョン2.7.0をリリースしました。

github.com

今回は2年以上ぶりのメジャーバージョンアップですが、今回はScala 2.13への対応、メンテナンス性向上のためにあまり使われていないモジュールやScalatra 2.6系ですでに非推奨になっていた機能の削除がメインとなっています。

Swaggerサポートに関してはいくつかの修正や機能追加が行われています。また、TwirlおよびScalateサポートにはScalatra Formsを便利に使用するためのヘルパーが追加されています。Scala 2.13のサポートにあわせて本体のコアクラスにもいくつか手が入っている箇所がありますが、Scalatra 2.6.0で稼働していたアプリケーションは非推奨機能を使用していない限り、ほぼそのままScalatra 2.7.0でも動作するはずです。

詳細な変更内容は以下のアナウンスを参照していただければと思います。 https://scalatra.org/2020/03/01/2020-03-01-scalatra-2-7-0-released.html

当初やSwagger 3.0のサポートやJSONサポートの改善なども計画していたのですが、なかなか手が回りませんでした。今後についても現在の自分の状況やコミッタのリソースを考えるとなかなかアクティブに開発を進めていけるとは言い難い状況ではありますが、すでに安定したフレームワークですので最新のScalaのバージョンへの追従をメインに引き続きメンテナンスを継続していこうと思います。

HHKB Professional2用の吸振マットを買ってみた

f:id:takezoe:20200229102348j:plain

ThinkPadキーボードのトラックポイントが実は肩コリの原因なのではという疑惑により最近は再びHHKBと普通のマウスを使う生活をしています。最初はHHKBのキーストローク辛いなぁと思っていたのですが、すっかり慣れてしまいました。肩コリは多少改善したような気がします。

さて、少し前にHHKB用の振動吸収マットなるものが存在することを知り試してみたいと思っていたのですが、PFUオンラインストアでは品切れになっていたので諦めてコルクシートでマットを自作したりなど涙ぐましい努力をしていたところ、Amazonで売っていたのでここぞとばかりに購入してみました。

日付が変わってからクリックしたのですが、その日のうちに自宅に届きました。早速装着。エンボス加工されたマットで筐体の裏側一面が覆われます。

実際にタイプしてみると明らかに筐体が安定し、特に底打ちした時のキータッチが柔らかくなっています。HHKBは筐体がプラスチックで軽量なため、タイプしていると筐体がズレたりデスクからの反動を感じたりするのが欠点の一つだと個人的に思っているのですが、このマットを装着するとデスクにグリップして微動だにしなくなります。一度貼ってしまうと剥がすのが大変そうでですし、値段もそこそこしますが、ただでさえ素晴らしいHHKBのキータッチがさらにいい感じになるのでHHKBユーザの方は是非試してみて欲しいです。

なお、今回購入したのはProfessional 2用のものですが、最新のHybrid用のマットも販売されています。こちらもPFUオンラインストアでは現在品切れ中ですが、Amazonで購入することができます。

HHKB吸振マットHG(HYBRID Type-S,HYBRID,Classic用)

HHKB吸振マットHG(HYBRID Type-S,HYBRID,Classic用)

  • メディア: エレクトロニクス

Amazon Builder's Libraryを読んでみた

昨年のre:Invent 2019で発表されたAmazon Builder's Libraryを一通り読んでみました。通勤電車で読んでいたのですが、途中で冬休みに突入してしまい少し時間がかかってしまいました。途中で日本語にも対応していることに気付いたのですが、折角なので全て英語で読んでみました。

aws.amazon.com

Amazonにおける大規模分散システムの開発で得られたノウハウが公開されているのですが、昨今マイクロサービスの普及もあり、Amazonのような規模でなくとも分散システムに関するノウハウが重要になりつつあります。もちろんAWSのインフラや規模感に依存する部分も多々見られるものの、大規模な分散システムを運用した上で得られる知見というのは得難いものですし、一般論として参考になる部分も多く、とても有用なコンテンツだと思います。

全体を通して共通して述べられていたのは以下のような点です。

  • 複雑な仕組みはなるべく避ける
    • 複雑な仕組みにはテストが難しくなったり、トラブル時により状況を悪化させるリスクもあるので、きちんとメリット・デメリットを検討した上で本当に必要な場合のみ採用すること。また、すでに検証済みのライブラリなどは存在するのであればそれを使用し、車輪の再発明は避けること。
  • できるだけメトリックを取る
    • 何かしら判断を下す際に判断材料となるメトリックが必要。トラブルシュート時なども事前に適切なログ、メトリックが出ていると助けになる。具体的にどのようなログを取るべきかは各記事で説明されていますし、総論としてのロギングに関する記事もありました。

基本といえば基本ですが、どの記事でも繰り返し述べられていたのでやはりこういう部分が大事なんだなということを再確認させられました。

個人的には以下の記事が面白かったです。

  • Avoiding fallback in distributed systems
    • トラブル時のフォールバックはテストが難しい上に問題があってもすぐに発覚しないことが多いなどデメリットが大きいので避けるべきという話。もちろんケースバイケースだとは思うのですが、何も考えずに気軽にフォールバック処理を埋め込んでしまうのはよくないなぁという気付きがありました。
  • Leader election in distributed systems
    • Leader ElectionはカナリーデプロイやA/Bテストなどのための部分デプロイと相性が悪いというのは言われてみればという感じ。システムを冪等に作っておくことでトラブル時など複数のLeaderが存在する状態になってしまっても問題ないようにしておくなど、なるほどと思う点が多かったです。
  • Using load shedding to avoid overload
    • 高負荷時にキャパシティを超えたリクエストを拒否することで受け付けたリクエストのレイテンシを守るという手法。ヘルスチェックやオートスケーリングとの競合など気を付けないといけない点が多く実際にはなかなか扱いが難しそうですが、そういう部分も含めて興味深い記事でした。
  • Workload isolation using shuffle-sharding
    • Route53でDDoS攻撃の影響を最小限に抑えるために考案されたShuffle Shardingという手法について。シャッフルしたユーザの組み合わせを複数シャードにアサインしておくことで攻撃を受けているユーザ以外に影響が出ないようにするというもの。Route53の開発秘話的な面もあり面白かったです。

前述の通り、各記事は日本語でも読むことができますが、恐らく機械翻訳と思われ、記事によっては意味がよくわからない箇所もあったので英語で読んだ方がいいかもしれません。1つずつの記事が適度な長さ(一部やや長めの記事もありますが)ですし、AWSユーザであれば見知った概念やキーワードも多いのでさほど詰まらずに読み進めることができると思います。

マイクロサービス時代のWeb開発では避けて通れない話題がコンパクトにまとめられていますので、まだご覧になっていない方は一度目を通されてはいかがでしょうか。FAQによると今後も定期的に記事が追加される予定とのことなので要チェックです。

100均のコルクシートでキーボードマットを作ってみた

f:id:takezoe:20200102010127j:plain

HHKBを自宅のデスクで使っていると結構タイプ音が響くし底打ちした時の反動も感じるなぁと思っていたのですが、どうやらHHKBの裏に貼り付けられる吸振マットなるものが存在するらしいということを知り、クリックしようと思ったところすでにHHKB Pro2用のものは在庫切れとのこと。

www.pfu.fujitsu.com

悲しい気持ちになりながらインターネッツを彷徨っていたところ以下の記事を発見しました。

freelance.go-creators.com

これなら簡単にできそうだし値段も安いので試してみようということで早速近所の100均(キャンドゥ)でコルクシートを買ってきてトライしてみました。

f:id:takezoe:20200102010143j:plain

こんな感じで現物合わせで適当に線を引いてはさみでチョキチョキ切るだけ。簡単です。

HHKBは筐体がプラスチックということもあり、金属プレートが入ったメカニカルキーボードと比べるとデスクによって結構タイプ感が変わる感じがありますが、コルクシートを敷くことで底打ちした時の反動が和らぎ、ソフトなタイプ感になりました。ただ、あくまでただのコルクシートなのでグリップはしません。本体に貼り付ける必要もありませんし、まあ100円にしては上出来かなと思います。サイズも自由に決めることができるのでHHKB以外のキーボード用のものも作ることができます。

今回は1枚のコルクシートから3枚分作ることができたので1枚はオフィスで使ってみようかと思います。