PostgreSQL
PostgreSQLデータベースをホストする5つの方法
はじめに
プロジェクトや組織で使用するためのPostgreSQLインスタンスを取得する方法はたくさんあります。PostgreSQLを自分でインストールして構成する方法を学ぶことも、サービスプロバイダーにお金を払ってPostgreSQLデータベースを管理してもらうこともできます。
このガイドでは、PostgreSQLを実行するさまざまな方法と、それぞれの利点と欠点について説明します。さまざまなオプションを比較することで、プロジェクトや開発段階に最適なソリューションの種類についての理解を深めることができるはずです。
自己管理型PostgreSQL
最も柔軟で説明が簡単なオプションは、PostgreSQLサーバーを自己ホストすることです。PostgreSQLを自己ホストするということは、他のソフトウェアと同様に、制御するコンピューターにデータベースをインストールして構成することを意味します。
自己ホストにより、データベースをインストールして実行する場所について多くの選択肢が得られます。このセクションのオプションのいずれかを選択した場合、このガイドを使用して、システムにPostgreSQLをインストールする方法を学ぶことができます。
ローカル開発コンピューターへのPostgreSQLのインストール
初期開発、テスト、および概念実証のために、ローカル開発マシンにPostgreSQLをインストールすると、信頼性が高く、管理が簡単なデータベースへのアクセスを提供できます。
| ホスティングオプション | ローカル開発マシン |
|---|---|
| プロジェクト段階 | 開発 |
| コスト | 追加コストなし |
| パフォーマンス | 低い |
| スケーラビリティ | なし |
| 管理の複雑さ | 低い |
| 追加の注意 | ネットワーク構成は不要です。ローカル開発に適しています。 ローカル開発に適しています。 |
コスト
開発マシンにPostgreSQLを設定するのは無料です。開発中にすでにアクティブになっているコンピューターからデータベースを実行しています。PostgreSQLが起動して実行されているときに消費するリソースの量を考慮するだけで済みます。
パフォーマンス
開発マシンにPostgreSQLをインストールするのは、低パフォーマンスのオプションです。
データベースは、他のユーザーが簡単かつ確実に利用できるわけではありません。データベースの独自の利用は、ハードウェアとPostgreSQLに割けるリソースの量によって制限されます。これらの懸念事項は、ローカルでテストまたは開発する場合、通常は問題になりませんが、より複雑なものにはまったく不十分です。
スケーラビリティ
開発マシンでのホスティングでは、スケーラビリティはほとんど得られません。PostgreSQLに割り当てるリソースの量を変更できますが、それ以上はほとんどできません。開発マシンをアップグレードできますが、長期的には実用的でも特に役立つわけでもありません。
管理の複雑さ
複雑さの点で、ローカルマシンでのPostgreSQLのホスティングは、多くの場合、非常に簡単です。ほとんどのオペレーティングシステムのインストールプロセスは十分に検討されており、結果として得られるデータベースは簡単に起動または停止できます。ただし、リソースの制限とコンシューマーネットワークの不安定さを考えると、ローカルPostgreSQLインスタンスを外部アクセス用に構成するのは通常、努力する価値はありません。
ローカルでPostgreSQLを設定するのは複雑ではありませんが、それでもデータベースを管理し、必要に応じてアップグレードを実行する必要があります。これらは、セキュリティパッチの適用に時々必要になる可能性があり、データが気になる場合は、これらのインスタンスを追跡するのはあなたの責任になります。
追加の注意
ローカルにインストールするということは、ネットワークがダウンしている場合でも、開発コンピューターからデータベースにアクセスできることを意味します。これは、旅行中に特に役立ちます。ローカルでデータにアクセスすると、ネットワークの複雑さが軽減され、データベースアクセスではなく開発に集中できます。
ローカル開発コンピューターへのPostgreSQLのインストールは便利ですが、いくつかの明確な制限があります。マルチユーザーアクセスを簡単に構成することはできず、データベースの稼働時間は、コンピューターの可用性とネットワークの安定性に直接結び付いています。これらの理由から、開発マシンへのインストールは、生産性と柔軟性を高めるための補助的なオプションであり、決して唯一のデータベースインストールではありません。
別のサーバーへのPostgreSQLのインストール
別の自己ホストオプションは、別のコンピューターにPostgreSQLをインストールして管理することです。一般的な実装には、次のものがあります。
- 専用サーバーへのインストール：PostgreSQLは、専用コンピューターで実行される唯一のサービスとして構成されています。マシンのすべてのリソースにアクセスできます。
- 関連アプリケーションと並行したインストール：PostgreSQLは、それを必要とするアプリケーションと並行してインストールされます。これは、すべてのコンポーネントを単一のマシンで管理できるため、小規模なデプロイメントに人気のある選択肢です。コンピューターのリソースは、PostgreSQLと他の実行中のアプリケーション間で共有する必要があります。
別のサーバーへのPostgreSQLのインストールは、開発マシンへのインストールとは大きく異なります
| ホスティングオプション | 別のサーバー |
|---|---|
| プロジェクト段階 | 開発、ステージング、本番環境 |
| コスト | 可変。追加のサーバーの購入またはレンタル サーバーに加えて、追加の管理コスト。 |
| パフォーマンス | 高い可能性 |
| スケーラビリティ | 高い可能性 |
| 管理の複雑さ | 高い |
| 追加の注意 | 最も柔軟なオプション。また、最も多くの実践的な管理が必要です。社内にハードウェアまたはデータベースの専門知識がある場合に適した選択肢です。 最も多くの実践的な管理が必要です。社内にハードウェアまたはデータベースの専門知識がある場合に適した選択肢です。 社内にハードウェアまたはデータベースの専門知識があり、管理に専念できる場合に適した選択肢です。 社内にハードウェアまたはデータベースの専門知識があり、管理に専念できる場合に適した選択肢です。 |
さらに強調する必要のある考慮事項の1つは、PostgreSQLを自分で管理する場合、セキュリティはあなたの責任であるということです。組織の他の部分のインフラストラクチャ、ソフトウェア、ネットワークセキュリティをすでに処理している場合は、問題ないかもしれません。ただし、あまり詳しくない場合は、PostgreSQLインスタンスとそれが保持するデータを保護することは、大きな課題になる可能性があります。このパスを選択する前に、これを計画に組み込むようにしてください。
コスト
専用または共有マシンでPostgreSQLを実行するには、使用するサーバー領域を購入またはレンタルする必要があります。実際のサーバーは、組織のオンプレミス、データセンター内のコロケーション、またはクラウドプロバイダーがホストする仮想マシン（仮想プライベートサーバーまたはVPSとしても知られています）として運用される場合があります。
サーバーのコストは大きく変動する可能性があります。低電力のVPSは非常に安価である可能性がありますが、複数の専用サーバーはすぐに高価になります。ただし、サーバーのコストだけが考慮事項ではありません。追加の管理コストも考慮に入れる必要があります。デプロイメント環境によっては、データベース層、サーバーのソフトウェア、およびハードウェアを管理するための人件費が含まれる場合があります。これらのコストは、可用性の要件、ホスティング環境、および運用の規模によって異なります。
パフォーマンス
別のサーバーへのPostgreSQLのデプロイは、非常に高いパフォーマンスの可能性があります。PostgreSQLを実行するマシンの仕様はあなたの管理下にあるため、ニーズに合ったハードウェアを完全に柔軟に選択できます。将来拡張する必要がある場合は、ハードウェアをアップグレードするか、追加のサーバーを購入してワークロードをスケールできます。
データベース構成を微調整して、パフォーマンスの利点をさらに高めることもできます。メモリ管理、キャッシュ、オープンファイル処理、クライアント接続などに関連する設定を調整できます。これにより、多くの機能が提供されますが、これらのオプションを活用するには、時間、専門知識、および実験が必要です。独自のサーバーの実行の他の側面と同様に、利点は、プロジェクトのこの側面に割り当てることができる時間と費用によって制限されます。
スケーラビリティ
上記のように、専用サーバーで実行すると、データベースシステムの変化する要求に対応できます。データベースサーバーにリソースとハードウェアを追加してスケールアップするか、PostgreSQLサーバーのプール全体でリクエストのバランスを取ることによりスケールアウトできます。どちらのオプションも、さまざまな種類のストレスに対する合理的な対応です。
管理の複雑さ
一般的に言って、スケーリングにはパフォーマンスチューニングと同じ利点と制限があります。信じられないほどの柔軟性と能力がありますが、コストと構成の管理はあなたの責任です。追加のハードウェアを必要とする変更（需要の増加など）は、組織がハードウェアを調達し、ソフトウェアを構成し、ワークロードのバランスを取るための時間を確保するために、プロアクティブな監視と組み合わせる必要があります。
追加の注意
要約すると、独自のPostgreSQLを管理することは、信じられないほど効率的で強力で柔軟性がありますが、多くの専任の時間とリソースが必要になる可能性があります。このオプションは、データベースのランタイム環境、構成、およびアーキテクチャトポロジを制御したい社内インフラストラクチャとサーバーの専門知識を持つ組織に最適です。
Dockerを使用したPostgreSQL
別の自己ホストオプションは、Dockerを使用してPostgreSQLをコンテナとして実行することです。Dockerを使用すると、ローカルまたはリモートマシン上の隔離された環境でPostgreSQLを実行できます。
| ホスティングオプション | Dockerコンテナ |
|---|---|
| プロジェクト段階 | 開発、ステージング、本番環境 |
| コスト | 可変。追加のサーバーの購入またはレンタル サーバーに加えて、追加の管理コスト。 |
| パフォーマンス | 中〜高 |
| スケーラビリティ | 高い |
| 管理の複雑さ | 中〜高 |
| 追加の注意 | コンテナ化されたインフラストラクチャは、複雑さの点で劇的に異なる可能性があります。コンテナは多くのことを容易にしますが、特に開発およびステージング中、本番環境で適切に実行するには、経験と複雑なオーケストレーションも必要になります。 コンテナ化されたインフラストラクチャは、複雑さの点で劇的に異なる可能性があります。コンテナは多くのことを容易にしますが、特に開発およびステージング中、本番環境で適切に実行するには、経験と複雑なオーケストレーションも必要になります。 コンテナは多くのことを容易にしますが、特に開発 およびステージング中、本番環境で適切に実行するには、経験と 複雑なオーケストレーションも必要になります。 本番環境のワークロードの場合、コンテナは Kubernetesのようなコンテナオーケストレーションにすでに投資している場合にのみ、適切な選択肢となる可能性があります。 Kubernetesのようなコンテナオーケストレーションにすでに投資している場合にのみ、適切な選択肢となる可能性があります。 |
従来のローカルインストールよりもDockerを使用する利点には、次のようなものがあります。
- 公式のPostgreSQL DockerイメージでPostgreSQLを実行すると、PostgreSQLをインストールするよりも手間が少なくなります。
- Dockerを使用すると、複数の環境でまったく同じデータベース構成を再現できます。これは、同じPostgreSQL構成を必要とするプロジェクトで共同作業するチームに役立ちます。
- Dockerを使用して、PostgreSQLに割り当てるCPU、メモリ、およびストレージリソースを制御できます。
- Dockerは、PostgreSQLとマシンで実行されている他のソフトウェアとの間の非互換性の可能性を減らします。
ローカルまたはリモートマシンにDockerを使用してPostgreSQLをインストールすることは似ていますが、本番環境のワークロードにPostgreSQLを使用するかどうかによって、いくつかの追加の考慮事項があります。
DockerはPostgreSQLの実行の特定の側面を簡素化しますが、注意すべきいくつかのトレードオフがあります
- 構成によっては、Dockerで実行すると、ネットワーク構成の複雑さが増す可能性があります。
- Dockerは抽象化の追加レイヤーを追加します。これには、追加のセキュリティ上の考慮事項が必要であり、トラブルシューティングが直接的でなくなる可能性があります。
コンテナとKubernetes
Kubernetesを使用すると、複数のサーバーで構成されるクラスターでDockerコンテナを実行できます。クラスター内の1つのサーバーをメンテナンスのために停止する必要がある場合、基盤となるデータパーティションがアクセス可能である限り、KubernetesはPostgreSQLコンテナを別のサーバーに移動します。PostgreSQLを使用するアプリケーションをKubernetesで実行することもできます。これにより、アプリケーションとPostgreSQL間のネットワーク遅延を短縮できます。
マネージドサービス
独自のPostgreSQLを実行する代わりに、プロバイダーからPostgreSQLデータベースをレンタルまたは購入するという方法もあります。マネージドサービスを使用すると、PostgreSQLソフトウェアまたは基盤となるサーバーの舞台裏の管理を気にすることなく、データベースをサービスまたはAPIとして簡単に操作できます。
さまざまなニーズに対応するために、さまざまなタイプのマネージドサービスが存在します。このセクションでは、ホスティングプロバイダーまたはクラウドプロバイダー、サードパーティのマネージドデータベース、およびアプリケーションプラットフォームによって提供されるデータベースによって提供されるサービスについて説明します。
クラウドプロバイダーによって管理されるデータベース
おそらく最も一般的なタイプのマネージドPostgreSQLホスティングは、クラウドまたはホスティングプロバイダーが提供する種類です。これらの例としては、Amazon Web ServiceのRDS（リレーショナルデータベースサービス）、Google Cloud PlatformのCloud SQL、およびAzure Databaseなどがあります。
| ホスティングオプション | クラウドプロバイダー管理 |
|---|---|
| プロジェクト段階 | 開発、ステージング、本番環境 |
| コスト | 選択と使用状況に応じて大きく異なります。 選択と使用状況に応じて大きく異なります。 |
| パフォーマンス | 非常に可変 |
| スケーラビリティ | 高い |
| 管理の複雑さ | 低い |
| 追加の注意 | アプリケーションを実行できる同じクラウドプロバイダーによって提供されることが多い、高度にスケーラブルなソリューション。 アプリケーションを実行できる同じクラウドプロバイダーによって提供されることが多い、高度にスケーラブルなソリューション。 これにより、独自のサーバーを実行する手間をかけずに、ネットワークとパフォーマンスをさらに制御できます。 これにより、独自のサーバーを実行する手間をかけずに、ネットワークとパフォーマンスをさらに制御できます。 独自のサーバーを実行する手間をかけずに、ネットワークとパフォーマンスをさらに制御できます。 |
クラウドプロバイダーは、データセンターで実行するように微調整され、他のサービスとシームレスに連携する、さまざまなPostgreSQLデータベースを提供しています。
クラウドプロバイダー
次のクラウドプロバイダーは、ニーズに応じて購入、構成、およびスケーリングできるマネージドPostgreSQLデータベースを提供しています
サーバーとPostgreSQLの大部分はホスティングプロバイダーによって管理されますが、スケーリングオプションの設定、設定の微調整、アクセスの管理を行うことができます。データベースをインターネットから接続可能にするか、同じプロバイダーによって管理されているアプリケーションに直接接続するように構成できます。
コスト
クラウドプロバイダーによって管理されるPostgreSQLデータベースは、幅広いコストになる可能性があります。ローエンドでは、一部のプロバイダーは、最小限のパフォーマンスと稼働時間で無料の層を提供しています。ハイエンドでは、予期しないトラフィックの急増が発生した場合、需要を満たすために自動的にスケーリングすると、一晩で数千ドルの費用がかかる可能性があります。クラウドのほとんどのことと同様に、実際の使用量は毎月の請求に影響します。多くのクラウドは、使用量/コストが特定のポイントを超えた場合に、コストアラートまたは自動オフさえ提供しています。データベースシステムの運用コストを管理するには、使用量を監視し、カットオフを構成することが重要です。
スケーラビリティ
コストは予測が難しい場合がありますが、良いニュースは、クラウドでのスケーリングは非常に簡単であるということです。データベースに割り当てられたリソースは、オンザフライで構成可能です。つまり、アカウントの設定を変更するだけで、ストレージ容量、メモリとコンピューティング能力、またはデータを管理するレプリカの数を増やすことができます。注意深く構成されていない場合、高コストの原因となる可能性のある強力な機能の1つは、現在の需要に応じてデータベースのリソースを動的にスケーリングする機能です。これにより、コストをカバーできると仮定すると、常に要件を満たす容量を確保できます。
パフォーマンス
スケーラビリティに関連して、パフォーマンスはクラウドで信じられないほど柔軟なもう1つの領域です。使用パターンに応じて、データベースのパフォーマンスに最大の影響を与える設定を微調整することがよくあります。現在の構成が非力な場合は、追加のリソースを割り当てることもできます。データベースを使用するアプリケーションとデータベースをコロケーションすると、データベースとアプリケーション間のネットワークパフォーマンスを向上させることもできます。
管理の複雑さ
管理の複雑さの点で、クラウドホスト型データベースはかなりシンプルです。プロバイダーに管理の負担のほとんどを肩代わりしてもらうために料金を支払っています。それでもアカウントとデータベースに影響を与える設定を制御する必要がありますが、ハードウェア、オペレーティングシステム、およびPostgreSQL構成の大部分は処理されます。これは、データベースの使用の管理オーバーヘッドを削減する上で大きな影響を与える可能性がありますが、特別な場合には、希望するレベルのチューニングにアクセスできない場合があります。
追加の注意
一般に、クラウドプロバイダーによって管理されるPostgreSQLデータベースの料金を支払うことは、通常、魅力的なオプションです。管理作業の量を減らしながら、スケーリングとパフォーマンスに関して優れた柔軟性を提供します。クラウドプロバイダーのデータベースオファリングを利用することの欠点は、特定のレベルで通常よりも多く支払うことになる可能性があることです。さらに、ツールがプロバイダー固有の機能に大きく依存し始めると、現在のプロバイダーに閉じ込められる危険性があります。
サードパーティのマネージドデータベース
クラウドプロバイダーから直接データベースを購入する代わりに、サードパーティプロバイダーを通じてデータベースを管理することを選択できます。ほとんどの場合、このオプションは、データベース管理を基盤となるリソースプロバイダーから切り離し、選択したクラウドまたはクラウドにデータベースをデプロイおよび管理します。
| ホスティングオプション | サードパーティ管理 |
|---|---|
| プロジェクト段階 | 開発、ステージング、本番環境 |
| コスト | 選択に応じて大きく異なります 選択と使用状況に応じて大きく異なります。 |
| パフォーマンス | 非常に可変 |
| スケーラビリティ | 高い |
| 管理の複雑さ | 低い |
| 追加の注意 | サードパーティのマネージドデータベースには、クラウド提供のデータベースと同じ利点が多数あります。 サードパーティのマネージドデータベースには、クラウド提供のデータベースと同じ利点が多数あります。 ただし、サードパーティを通じてデータベースを管理することで、データベース管理を基盤となるクラウドプロバイダーから切り離すことができます。 ただし、サードパーティを通じてデータベースを管理することで、データベース管理を基盤となるクラウドプロバイダーから切り離すことができます。 ただし、サードパーティを通じてデータベースを管理することで、データベース管理を基盤となるクラウドプロバイダーから切り離すことができます。 これにより、将来別のホストに移行することが容易になり、場合によってはより強力な管理オプションが可能になります。 これにより、将来別のホストに移行することが容易になり、場合によってはより強力な管理オプションが可能になります。 これにより、将来別のホストに移行することが容易になり、場合によってはより強力な管理オプションが可能になります。 |
サードパーティプロバイダーによって管理されるデータベースは、クラウドプロバイダー自身が提供するものと同じ基本的なコンポーネントをしばしば使用します。しかし、サードパーティプロバイダーは多くの場合、複数のクラウドと連携し、ユーザーのアカウントでリソースを立ち上げ、必要に応じて低レベルのアクセスを提供することがよくあります。クラウドプロバイダーが提供するデータベースの代わりに、このサービスはプロバイダー上の仮想サーバーを起動し、これらを使用してPostgreSQLをインストールおよび構成します。オペレーティングシステムの設定を調整したり、インスタンスをホストするサーバーへのアクセスを提供したりできます。サードパーティのPostgreSQLプロバイダーの例としては、現在4つの異なるクラウドでインスタンスを管理できるElephantSQLがあります。
サードパーティの製品
以下のサードパーティプロバイダーは、ニーズに応じて購入、構成、およびスケールできるマネージドPostgreSQLデータベースを提供しています。
- Aiven
- Compose
- ElephantSQL
- Database Labs
- ScaleGrid
サーバーとPostgreSQLの大部分はプロバイダーによって管理されますが、データベースを実行するクラウドプラットフォーム、スケーリングオプションの設定、設定の微調整、およびアクセス管理を行うことができます。データベースをインターネットから接続可能に構成したり、同じプロバイダーによって管理されているアプリケーションに直接接続したりできます。
コスト
コストに関して言えば、サードパーティソリューションもまた非常に変動しやすいものです。ユーザーとして、デプロイ先のクラウドのコンピューティングリソースと、データベース管理サービスが請求する管理コストを支払う必要があります。マネージドデータベースではなく、より基本的なリソースに対してクラウドプロバイダーに支払うため、その側のコストは小さくなる可能性があります。ただし、管理サービスに関連するコストは、ある価格帯では累積的に高くなる可能性があります。総コストを決定するには、各側がさまざまなレベルでどのようにスケールするかを把握する必要があります。
パフォーマンス
データベースのパフォーマンス特性も大きく異なる可能性があります。管理サービスはクラウドのコンピュートインスタンスにインストールされるため、プロバイダーはPostgreSQLの設定に加えてサーバー構成を調整する能力を持っています。これは、ニーズにより合理的に一致するようにいくつかの設定を調整できる可能性があることを意味します。
一方で、十分に調整するために必要な仮想化およびハードウェアコンポーネントの低レベルレイヤーへのアクセス権がない場合があります。クラウドプロバイダーが提供するネイティブデータベースに対してパフォーマンスをテストすることを強くお勧めします。
スケーラビリティ
サードパーティ管理のデータベースのスケーラビリティは、一般的に非常に優れています。これらのプロバイダーは、十分なリソースを備えた任意のコンピュートインスタンスにデプロイできるため、クラウドプロバイダーが公開するよりも幅広いスケーリングオプションを提供できる場合があります。スケーリングの理由の1つが可用性の向上である場合、多くのサードパーティサービスは、複数のアベイラビリティゾーンまたはプロバイダーにまたがる機能を持っています。
管理の複雑さ
データベースを管理するためのサードパーティサービスには、さまざまな複雑さがあります。このオプションでは、2つの異なるプロバイダー（コンピュートインスタンスをホストするクラウドとデータベース管理サービス）間の連携が必要になるため、クラウドプロバイダーが提供するネイティブデータベースサービスを使用する場合と比較して、本質的に複雑さが増します。
一部の管理サービスは、共有ウェブホスティングとほぼ同じ方法で複雑さを隠蔽し、簡略化されたオプションとして位置付けています。他のソリューションは、オペレーティングシステムにアクセスできるという事実を活用して、幅広い構成オプションをユーザーに公開しています。多くのサービスは、ユーザーが好みの複雑さのレベルを見つけられるように、両方のエクスペリエンスを提供しています。
追加の注意点
データベース管理を基盤となるリソースプロバイダーから分離することには、利点と欠点の両方があります。
データベース管理サービスが基盤となるレイヤーを抽象化する場合、別のクラウドプロバイダーへの移行がより柔軟になる可能性があります。この抽象化により、快適な複雑さのレベルを選択することもできます。データベース管理サービスによって提供される完全な抽象化とインターフェースを使用できますが、プロビジョニングされたデータベースサーバーへのアクセス権もあるため、ログインして必要に応じてデータベースサーバーを変更できます。データベース管理サービスは、これらのオペレーティングシステムレベルの調整を管理するための簡単なインターフェースを提供する場合もあります。
このセットアップの欠点は、データベースの正しい動作を複数の当事者に依存することになるという事実に由来します。これにより、サービス中断の可能性が高まる可能性があります。また、クラウドプロバイダーが提供するデータベースサービスで利用可能な隠れた最適化を見逃す可能性もあります。データベース管理サービスは、クラウドプロバイダーが公開するものにのみアクセスでき、基盤となる仮想化レイヤーまたはハードウェアレイヤーを最適化することはできません。
全体として、サードパーティの管理サービスの使用は、好みとテストの問題です。パフォーマンスをテストし、価格体系がさまざまなレベルの使用状況でどのように影響するかを理解する必要があります。
まとめ
ここでは、ここで議論されたさまざまなオプションが互いにどのように比較されるかの概要を示します。
データベースをホストするための適切な選択は、アプリケーションの要件、開発段階、およびPostgreSQLを独自に管理する能力に大きく依存します。異なる選択肢は、特定の時期または特定の組織にとってより適切なものにするこれらの要因間のトレードオフを提供します。
PostgreSQLデータベースを入手したら、Prisma Clientを使用して、JavaScriptまたはTypeScriptアプリケーション内から管理できます。既存のプロジェクトにPrismaを追加する方法、またはPrismaをゼロから開始する方法をご覧ください。
Justin Ellingwood
Justinは、2013年からデータベース、Linux、インフラストラクチャ、および開発者ツールについて執筆しています。彼は現在、妻と2羽のウサギと一緒にベルリンに住んでいます。彼は通常、三人称で書く必要はありませんが、それは関係者全員にとって安心です。